脑裂后无法选主，本质是多数派丢失与GTID不一致双重叠加，必须人工确认主集群、清理冲突节点并强制同步或重置；group_replication_force_members超时失败是因为脑裂时节点仍持有旧view，未处于完全离线状态，该命令仅在无任何活跃view时生效。
直接说结论：脑裂后无法选主，本质是多数派（quorum）丢失 + GTID不一致双重叠加，不能靠重启或重试解决，必须人工干预确认主集群、清理冲突节点、强制同步或重置。
为什么group_replication_force_members会超时失败？
这个命令只在集群完全失联、无任何 view 时生效，但脑裂场景下往往仍有部分节点维持着旧 view（比如两个子集群各自认为自己是 majority），此时执行 SET GLOBAL group_replication_force_members 会卡在等待新 view 成立，最终触发 Timeout on wait for view 错误。
- 它不是“指定谁当主”，而是“强制用这些地址重建一个全新组”，前提是所有目标节点都处于
OFFLINE或UNREACHABLE状态，且未参与任何活跃 view - 如果某个节点还在运行
GROUP_REPLICATION插件（哪怕状态是UNREACHABLE），它就会拒绝被强制加入 -
group_replication_unreachable_majority_timeout设再大也没用——超时控制的是“等待多数节点恢复通信”，不是“等待 force_members 生效”
怎么快速识别哪个子集群是合法主集群？
别猜，用 gtid_executed 和 performance_schema.replication_group_members 交叉比对。合法主集群 = 拥有最新事务序列 + 成员数 ≥ quorum（n/2 + 1）的子集。
- 在每个疑似主集群的节点上执行：
SELECT @@global.gtid_executed;，找gtid_set最大的那个（注意比较逻辑：A:1-100,B:1-50>A:1-99,B:1-50） - 查成员视图：
SELECT * FROM performance_schema.replication_group_members WHERE MEMBER_STATE = 'ONLINE';，确认该子集群在线节点数是否满足 quorum（例如 3 节点集群需至少 2 个 ONLINE） - 若两个子集群都满足 quorum（极少见，但偶发于网络抖动+配置宽松），说明
group_replication_member_expel_timeout设置过小，已误驱逐健康节点，需先调大再观察
如何让掉队节点安全重新加入？
掉队节点（比如原主重启后报 MY-011526）不能直接 start group_replication，必须先对齐 GTID 或清空本地事务。
- 首选方案：用
CLONE插件全量重建（MySQL 8.0.17+）
在目标节点执行：INSTALL PLUGIN clone SONAME 'clone.so';→CLONE INSTANCE FROM 'repl'@'target_ip':3306;→ 重启 mysqld - 次选方案：手动 reset + set gtid_purged（仅限确认无本地关键事务）
STOP GROUP_REPLICATION;→RESET MASTER;→SET GLOBAL gtid_purged = 'xxx';（填入主集群的gtid_executed值）→START GROUP_REPLICATION; - 严禁操作：
SET GLOBAL gtid_executed直接覆盖 —— 这会导致 binlog 与 GTID 不匹配，后续复制必然中断
为什么fenceWrites()在副本集群上会报错？
因为 fenceWrites() 是 ClusterSet 场景下专为主集群设计的操作，副本集群本身就不允许写入，调用它属于语义错误。
- 报错信息
ERROR: Unable to fence Cluster from write traffic: operation not permitted on REPLICA Clusters已明确提示用途边界 - 真正要保护副本集群不被误写，应确保其始终启用
super_read_only=ON，并检查group_replication_single_primary_mode=ON是否生效 - 如果副本集群意外接受写入（比如人为关闭
super_read_only），唯一安全做法是：停服 → 导出数据 → 与主集群比对差异 → 手动合并或丢弃
最易被忽略的一点：脑裂恢复后，group_replication_member_weight 的值会影响下次选举权重，但不会自动修复已分裂的 GTID 状态；所有干预动作都必须在确认单一边界（即唯一可信主集群）的前提下进行，否则只是把问题从“多主”变成“多残缺主”。
