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 生效的前提，是网络故障域必须相互独立。
