MySQL 8.0原生组复制MGR如何处理网络分区产生的脑裂？

MGR通过多数派投票机制自动防脑裂：3节点集群中，仅含≥2节点的子集群可写，其余自动只读或不可用；多数派失效时写操作立即阻塞，单节点进入ERROR状态并启用super_read_only，宁停写不分裂数据。

MySQL 8.0 原生 MGR 不靠“人工判断谁该活”，而是靠多数派投票自动拒绝少数分区的写入——只要节点数 ≥3 且配置正确，脑裂根本不会发生；一旦发生网络分区，**只有包含多数节点的子集群能继续写，其余自动只读或不可用**。

多数派（quorum）失效时写操作直接阻塞

MGR 的 Paxos 实现要求事务必须获得 floor(n/2) + 1 个节点确认才能提交。3 节点集群中，至少需要 2 个节点在线并通信；若只剩 1 个节点在线（比如另外两个因网络中断失联），该节点会立即进入 ERROR 状态，super_read_only=ON 自动生效，所有 DML 报错：

ERROR 3092 (HY000): The server is not configured properly to be an active member of the group. Only administrators can set super_read_only=OFF.

• 这不是 bug，是设计行为：宁可停写，也不允许数据分裂
• group_replication_unreachable_majority_timeout 默认为 0，意味着“多数不可达”即刻触发保护，不等待
• 若设为非零值（如 35），节点会在超时后尝试强制退出视图，但不会自行恢复写能力

为什么不能靠 group_replication_force_members 强制单节点启动？

这个变量常被误认为“救急开关”，但它只在集群完全宕机、无任何活跃视图时才有效；在网络分区场景下，只要还有子集群维持着合法视图（哪怕只有 2/3 节点），SET GLOBAL group_replication_force_members="x:x" 就会失败，并报：

ERROR 4118 (HY000): Timeout on wait for view after setting group_replication_force_members.

• 它不用于跨分区“选边站队”，而仅用于灾难恢复后的冷重启
• 强行设置会导致 GCS 层无法建立组通信，实例卡在 RECOVERING 或 ERROR
• 真实故障中，应优先检查 performance_schema.replication_group_members 确认当前视图成员，而非硬编码地址

单主模式下脑裂风险远低于多主，但配置易被忽略

默认 group_replication_single_primary_mode=ON 是防脑裂的第一道屏障。一旦网络分区，只有多数派子集群中的那个唯一主节点能写；少数派里的“原主”会自动降级为只读，不会抢写。

• 切勿在生产环境开启 group_replication_multi_primary_mode=ON 后不做应用层写路由控制——这等于主动放弃多数派保护
• 单主模式下，可通过 SELECT @@group_replication_primary_member; 实时查主节点 UUID，比依赖 IP 更可靠
• 如果业务强依赖“永远可写”，应评估是否真适合 MGR；更适合用 ClusterSet + fenceWrites() 手动隔离，而非让 MGR 自行扛分区

真正容易被忽略的不是参数怎么配，而是把“3 节点”当成万能解——若三个节点物理部署在同一交换机下，一次交换机故障就全进少数派；quorum 生效的前提，是网络故障域必须相互独立。