MySQL MGR多主模式需显式关闭read_only与super_read_only并设group_replication_consistency=AFTER，否则写入报错或静默回滚；冲突由WRITE_SET检测，依赖ROW格式与XXHASH64；法定数量校验要求≥3奇数节点。
MySQL Group Replication（MGR）默认不支持多主写入与强一致性共存——必须显式配置 group_replication_consistency 并禁用只读限制，否则多主节点会自动拒绝写入或产生不可预测的回滚。
多主模式启动前必须关闭只读限制
MGR 多主模式下，每个节点默认仍继承 MySQL 全局 read_only=ON 和 super_read_only=ON，这会导致 INSERT/UPDATE 直接报错 ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement。
- 在所有节点执行：
SET PERSIST read_only=OFF;和SET PERSIST super_read_only=OFF; - 确认生效：
SELECT @@read_only, @@super_read_only;返回均为0 - 注意：仅
SET GLOBAL不够，重启后失效；PERSIST写入mysqld-auto.cnf才持久
group_replication_consistency=AFTER 是强一致性的最低可行配置
该参数控制事务提交前是否等待集群内多数节点完成应用（apply），而非仅接收（receive）。设为 AFTER 时，事务在本地 commit 成功前，必须确保其他多数节点已将该事务写入 relay log 并完成 apply —— 这是防止“读到旧数据”的关键。
- 单主模式下设为
AFTER影响较小；多主模式下会显著增加写延迟，但避免了节点切换后SELECT返回陈旧值 - 不要用
BEFORE_AND_AFTER：它要求事务开始前先等集群同步就绪，多主并发写时极易触发超时和死锁 - 验证配置：
SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'group_replication_consistency';
多主写入冲突实际发生时，WRITE_SET 检测会静默回滚事务
MGR 不抛出 “duplicate key” 或 “deadlock” 错误，而是直接回滚冲突事务并记录到 error log，客户端收到的是 ERROR 1297 (HY000): Got temporary error 4011 from NDBCLUSTER 类似提示（实际错误码可能为 3092 或 3101）。
- 典型冲突场景：两个节点同时执行
UPDATE users SET balance = balance + 100 WHERE id = 1; - 冲突检测依赖
binlog_format=ROW和transaction_write_set_extraction=XXHASH64（默认） - 排查方式：
SELECT * FROM performance_schema.replication_group_members;确认状态为ONLINE；再查SHOW ENGINE INNODB STATUS\G中的LATEST DETECTED DEADLOCK区域无内容，说明不是 InnoDB 死锁，而是 MGR 层拦截
多主模式无法绕过法定数量（quorum）校验
只要集群节点数 ≤ 3，任意一个节点宕机就会导致剩余节点无法达成多数派（quorum = ⌊n/2⌋ + 1），整个集群拒绝新写入 —— 此时 START GROUP_REPLICATION 会卡住，SELECT * FROM performance_schema.replication_group_members 显示部分成员状态为 UNREACHABLE 或 ERROR。
- 生产环境务必部署 ≥ 3 个节点，且避免偶数节点（如 4 节点时，2-2 分裂即脑裂）
- 临时恢复手段有限：可通过
STOP GROUP_REPLICATION;+SET GLOBAL group_replication_force_members="ip1:port1,ip2:port2";强制重建视图，但会丢失未同步事务 - 该操作极危险，仅限故障定位阶段使用，不可写入自动化脚本
真正难处理的不是配置开关，而是多主写入后应用层如何应对静默回滚、如何设计幂等更新逻辑、以及如何监控 replication_group_member_stats 中的 COUNT_TRANSACTIONS_VALIDATING 和 COUNT_TRANSACTIONS_ROWS_VALIDATING 是否持续堆积 —— 这些才是线上稳定运行的分水岭。
