脑裂本质是“谁还能写”的决策问题，mgr依赖多数派和group_replication_consistency拦截非法写入；网络分区后节点状态残留导致online误判；group_replication_consistency应设before或after，禁用eventual；发现脑裂须立即冻结少数派写入，恢复前须确认多数派、事务一致性和流量路由。
脑裂不是“选主”问题，而是“谁还能写”的决策问题——MGR 本身不选举，只靠多数派 + group_replication_consistency 配置共同拦住非法写入。
为什么网络分区后部分节点报 ERROR 3092 却仍显示 ONLINE
这是最典型的脑裂误判现象：节点在 performance_schema.replication_group_members 中状态还是 ONLINE，但实际已失去多数派支持。MGR 的“多数派”判断只看当前视图中 MEMBER_STATE = 'ONLINE' 的节点数量，不校验网络连通性或心跳实效性。
- 常见诱因：3 节点集群缩容为 2 节点后未重设
group_replication_autorejoin_tries，或网络抖动导致某节点反复进出UNREACHABLE状态，但旧记录残留在视图中 - 验证方法：执行
SELECT COUNT(*) FROM performance_schema.replication_group_members WHERE MEMBER_STATE = 'ONLINE';，确认真实在线数是否 ≥ ⌊N/2⌋+1 - 清理残留：先在疑似失效节点上执行
STOP GROUP_REPLICATION;，再在其他健康节点执行SET GLOBAL group_replication_force_members = '';
group_replication_consistency 应该设 BEFORE 还是 AFTER
这个参数不控制故障转移，只决定事务能否提交——它才是脑裂时数据不一致的开关。
-
EVENTUAL：完全不等确认，少数派节点照常写入 → 脑裂后必然产生冲突事务，恢复时需人工合并 -
BEFORE：事务开始前检查本节点是否仍在多数派中 → 少数派节点直接拒绝新事务（报 ERROR 3092），避免脏写 -
AFTER：提交前要求所有多数派节点完成落盘 → 少数派节点卡在 commit 阶段，但多数派内强一致；缺点是延迟高、易阻塞 - 生产推荐：
BEFORE_ON_PRIMARY_FAILOVER（主切后自动升为 BEFORE）或AFTER，绝不用EVENTUAL
如何安全隔离少数派子集，防止误操作
发现脑裂后，第一反应不是重启或 START GROUP_REPLICATION，而是立刻冻结写入——否则少数派节点可能已写入不可合并的事务。
- 对确认为多数派的集群子集：保持运行，检查
group_replication_group_members确保无残留节点 - 对确认为少数派的节点：立即执行
SET GLOBAL super_read_only = ON;（禁用自动管理后再设） - 若使用 ClusterSet：在主集群上调用
cluster.fenceWrites()，它会批量启用super_read_only并关闭自动管理 - 严禁对少数派节点执行
START GROUP_REPLICATION—— 它会触发完整状态传输（SST），但其 binlog 已含被多数派拒绝的事务，极易引发 GTID 冲突或认证失败
恢复服务前必须确认的三件事
多数派确认、事务一致性、Router 流量切换——缺一不可，否则看似恢复了，实则埋下数据错乱隐患。
- 确认多数派：执行
SELECT MEMBER_HOST, MEMBER_STATE FROM performance_schema.replication_group_members;，确保至少 ⌊N/2⌋+1 个节点为ONLINE且彼此网络可达 - 确认事务边界：在多数派任一节点查
SELECT @@gtid_executed;，比对各节点是否一致；若有差异，说明有节点漏收事务，需手动补传或重建 - 确认流量路由：MySQL Router 必须指向多数派集群；若用 VIP，需确保 Keepalived 或类似工具已将 VIP 绑定到多数派中的 PRIMARY 节点
多数派判定逻辑简单，但容易被残留视图欺骗；group_replication_consistency 是唯一能主动拦截脑裂写入的开关；而 fenceWrites() 或手动 super_read_only 是防止二次污染的最后防线——这三者必须配合使用，单靠其中一个解决不了脑裂。
