如何在MySQL 8.0中利用MGR解决脑裂后的数据冲突？

MGR脑裂后无法自动恢复数据一致性，因其Paxos机制仅保证多数派写入成功，不保证所有节点最终一致；网络分区导致GTID分叉，触发MY-011526错误，且MGR不允许回退GTID或自动合并冲突事务。

不能靠自动修复，必须人工介入判断哪边数据可信，再手动重置 GTID 并重建复制关系。

为什么 MGR 脑裂后无法自动恢复数据一致性

MGR 的 Paxos 机制只保证“多数派写入成功”，不保证“所有节点数据最终一致”。一旦发生网络分区导致脑裂，两个子集群各自产生新事务，GTID 集合就会分叉。此时 START GROUP_REPLICATION 会直接报错 [my-011526]，因为本地已执行的 GTID 超出了当前组的已知范围。

1. 错误典型表现：this member has more executed transactions than those present in the group. local transactions: xxx:1-12 > group transactions: xxx:1-11
2. 根本原因：MGR 不允许“回退”GTID，也不支持自动合并冲突事务
3. 关键限制：即使启用 group_replication_allow_local_disjoint_gtids_join=ON，也仅适用于“尚未写入”的孤立节点，对已产生新事务的脑裂节点无效

确认哪边是可信主集群（必须做的第一步）

跳过这步直接操作等于覆盖真实业务数据。可信集群 = 网络分区期间持续对外提供写服务、且应用连接未中断的那一组节点。

1. 查各节点角色：SELECT MEMBER_ID, MEMBER_ROLE, MEMBER_STATE FROM performance_schema.replication_group_members;
2. 比对 GTID 连续性：SELECT * FROM mysql.gtid_executed; —— 可信集群的 GTID 序列应更长、无断点
3. 核对应用日志：确认业务写请求实际落在哪个子集群（例如 Nginx access log、应用数据库连接地址）
4. 警惕“假多数”：若三节点集群中 A/B 失联、C 单独存活，C 无法形成多数派（quorum=2），其写入属于非法状态，不可信

强制剔除冲突节点并重建复制

目标是让冲突节点以“全新空白实例”身份重新加入，而非尝试同步旧数据。

1. 在冲突节点上彻底清空 GTID 历史：RESET MASTER;（⚠️ 此操作不可逆，确保已备份）
2. 停掉组复制：STOP GROUP_REPLICATION;
3. 关闭 binlog 写入（避免残留事务干扰）：SET GLOBAL sql_log_bin = OFF;
4. 清空本地数据（或从可信集群全量克隆）：DROP DATABASE IF EXISTS your_db; 或用 mysqldump + mysql 恢复
5. 重新启用 binlog：SET GLOBAL sql_log_bin = ON;
6. 启动组复制：START GROUP_REPLICATION;

注意：RESET MASTER 会重置 mysql.gtid_executed 和 binlog 文件，这是绕过 [my-011526] 错误的唯一安全方式。任何试图保留本地 binlog 的方案都会失败。

最容易被忽略的环节：应用层连接切换与验证

数据库层恢复只是半程。应用若仍连着旧主或使用失效连接池，几秒内就会再次写入冲突节点。

1. 检查应用配置：确认连接字符串指向的是当前可信主集群的 VIP 或负载均衡器，而非具体 IP
2. 重启应用连接池：避免复用脑裂期间建立的长连接（尤其 Spring Boot 的 HikariCP 默认不主动检测失效连接）
3. 上线后立即验证：执行一条带时间戳的测试 DML，再查所有节点确认该事务是否出现在 SELECT * FROM mysql.gtid_executed; 中

真正的难点从来不在 SQL 命令怎么敲，而在于你能否在告警轰炸时快速锁定业务真实写入路径，并说服开发团队配合重启服务——否则所有数据库操作都是在给下一次脑裂铺路。