mysql 8.0组复制中脑裂本质是多数派失效，仅含多数节点的子集可写入，孤立节点自动置为error并只读；人为禁用super_read_only或绕过权限才导致不一致。
MySQL 8.0组复制中脑裂的本质是多数派失效，不是配置漏了
组复制（MGR）本身用Paxos协议保证多数派一致，但一旦网络分区导致集群分裂成两个孤立子集（比如3节点分成了1+2），只有包含多数节点（≥2）的子集能继续写入；剩下那个单节点会自动进入ERROR状态并拒绝写操作。所谓“脑裂”，其实是人为强行恢复孤立节点、绕过一致性机制造成的——MGR默认不会让你写，但DBA可能手动关super_read_only或重启实例，这就破防了。
必须关闭自动super_read_only管理才能触发脑裂
MGR默认开启group_replication_bootstrap_group=OFF且依赖super_read_only做安全阀。只要没动这个开关，单节点失联后立刻只读，根本写不进去。容易踩的坑是：
- 在MySQL Shell里执行
cluster.status()看到某个节点是UNREACHABLE或MISSING，却直接连上去执行SET PERSIST super_read_only = OFF - 用
mysqld --skip-grant-tables启动绕过权限检查，再改系统变量 - 误以为
group_replication_single_primary_mode=ON就绝对安全，忽略了多主模式下冲突检测仅对同一行生效，跨行并发更新仍可能产生不一致
网络分区后唯一安全的操作是fenceWrites()
当确认发生分区（比如监控发现group_replication_members只剩1个活跃节点），应立即用MySQL Shell连接到该节点所在集群，运行：
cluster.fenceWrites()
这个命令会：
- 禁用
group_replication_autorejoin_tries等自动重连逻辑，防止它偷偷尝试加入错误分组 - 强制所有实例启用
super_read_only=ON，哪怕你之前手动关过 - 关闭
group_replication_start_on_boot=OFF，避免重启后自动加入旧视图
注意：fenceWrites()不能在副本集群上运行，报错ERROR: Unable to fence Cluster from write traffic: operation not permitted on REPLICA Clusters说明你连错了集群角色。
恢复前必须人工校验GTID集合是否完整
分区修复后不能直接unfenceWrites()。先查两组节点的GTID：
SELECT @@global.gtid_executed;
如果A组有aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:1-100，B组只有1-50，说明B组缺失事务，必须从A组备份恢复，而不是简单重启MGR。MGR不会自动补齐缺失GTID，它只同步新事务。这点和传统主从完全不同——组复制没有“从某位置开始复制”的概念，只有“全量视图一致”或“拒绝加入”两种状态。
