MGR脑裂后无法自动恢复数据一致性，因其Paxos机制仅保证多数派写入成功，不保证所有节点最终一致；网络分区导致GTID分叉，触发MY-011526错误，且MGR不允许回退GTID或自动合并冲突事务。
不能靠自动修复，必须人工介入判断哪边数据可信，再手动重置 GTID 并重建复制关系。
为什么 MGR 脑裂后无法自动恢复数据一致性
MGR 的 Paxos 机制只保证“多数派写入成功”，不保证“所有节点数据最终一致”。一旦发生网络分区导致脑裂，两个子集群各自产生新事务，GTID 集合就会分叉。此时 START GROUP_REPLICATION 会直接报错 [my-011526]，因为本地已执行的 GTID 超出了当前组的已知范围。
- 错误典型表现：
this member has more executed transactions than those present in the group. local transactions: xxx:1-12 > group transactions: xxx:1-11 - 根本原因：MGR 不允许“回退”GTID，也不支持自动合并冲突事务
- 关键限制：即使启用
group_replication_allow_local_disjoint_gtids_join=ON，也仅适用于“尚未写入”的孤立节点，对已产生新事务的脑裂节点无效
确认哪边是可信主集群（必须做的第一步）
跳过这步直接操作等于覆盖真实业务数据。可信集群 = 网络分区期间持续对外提供写服务、且应用连接未中断的那一组节点。
- 查各节点角色：
SELECT MEMBER_ID, MEMBER_ROLE, MEMBER_STATE FROM performance_schema.replication_group_members; - 比对 GTID 连续性：
SELECT * FROM mysql.gtid_executed;—— 可信集群的 GTID 序列应更长、无断点 - 核对应用日志：确认业务写请求实际落在哪个子集群（例如 Nginx access log、应用数据库连接地址）
- 警惕“假多数”：若三节点集群中 A/B 失联、C 单独存活，C 无法形成多数派（
quorum=2），其写入属于非法状态，不可信
强制剔除冲突节点并重建复制
目标是让冲突节点以“全新空白实例”身份重新加入，而非尝试同步旧数据。
- 在冲突节点上彻底清空 GTID 历史：
RESET MASTER;（⚠️ 此操作不可逆，确保已备份） - 停掉组复制：
STOP GROUP_REPLICATION; - 关闭 binlog 写入（避免残留事务干扰）：
SET GLOBAL sql_log_bin = OFF; - 清空本地数据（或从可信集群全量克隆）：
DROP DATABASE IF EXISTS your_db;或用mysqldump+mysql恢复 - 重新启用 binlog：
SET GLOBAL sql_log_bin = ON; - 启动组复制：
START GROUP_REPLICATION;
注意：RESET MASTER 会重置 mysql.gtid_executed 和 binlog 文件，这是绕过 [my-011526] 错误的唯一安全方式。任何试图保留本地 binlog 的方案都会失败。
最容易被忽略的环节：应用层连接切换与验证
数据库层恢复只是半程。应用若仍连着旧主或使用失效连接池，几秒内就会再次写入冲突节点。
- 检查应用配置：确认连接字符串指向的是当前可信主集群的 VIP 或负载均衡器，而非具体 IP
- 重启应用连接池：避免复用脑裂期间建立的长连接（尤其 Spring Boot 的 HikariCP 默认不主动检测失效连接）
- 上线后立即验证：执行一条带时间戳的测试 DML，再查所有节点确认该事务是否出现在
SELECT * FROM mysql.gtid_executed;中
真正的难点从来不在 SQL 命令怎么敲，而在于你能否在告警轰炸时快速锁定业务真实写入路径，并说服开发团队配合重启服务——否则所有数据库操作都是在给下一次脑裂铺路。
