MGR多主模式通过writeset机制在提交前检测并回滚冲突事务，而非自动解决冲突；要求所有表有主键以生成准确writeset，应用层需收敛跨节点写同一业务实体，避免SELECT...FOR UPDATE长时间等待，且须严格配置group_replication_group_name、group_replication_local_address等参数。
能实现，但必须满足硬性前提：所有节点都用 InnoDB、每张表有主键、GTID 必须开启、binlog_format 必须为 ROW。不满足任意一条，group_replication 插件加载后也会拒绝启动或同步失败。
多主模式下事务冲突怎么避免？
MGR 不是“自动解决冲突”，而是靠 writeset 机制在提交前检测冲突——它提取每个事务修改的行级 write set（基于主键哈希），广播给组内其他节点比对。如果两个并发事务修改了同一行（哪怕在不同节点），后提交的那个会被直接回滚，并报错 ERROR 3098 (HY000): The table does not comply with the requirements... 或更常见的 ERROR 1290 (HY000): The MySQL server is running with the --read-only option（其实是冲突触发只读保护）。
- 必须确保所有表都有显式定义的主键，否则无法生成准确 writeset
- 避免跨分片更新同一业务实体（比如订单号同时在 A 节点更新状态、在 B 节点更新金额），这类逻辑需由应用层收敛到单节点写入
- 不要在事务里执行
SELECT ... FOR UPDATE后长时间等待，writeset 检测只发生在 COMMIT 前一刻，锁等待不参与冲突判断，但会拖慢整体吞吐
my.cnf 里哪些 MGR 参数不能抄错？
最容易出错的是 group_replication_group_name 和 group_replication_local_address。前者必须是合法 UUID（如 a5b7e8c1-2d4f-11ec-9621-0242ac130002），所有节点一致；后者必须写成“可被其他节点直连”的 IP:PORT（如 10.10.20.101:33061），不能写 localhost 或 127.0.0.1。
-
group_replication_start_on_boot=OFF：务必设为 OFF，防止 MySQL 启动时自动拉起组复制但网络未就绪 -
group_replication_bootstrap_group=ON：仅在初始化第一个节点时临时设为 ON，启动后立刻SET GLOBAL group_replication_bootstrap_group=OFF，否则第二个节点加入时会脑裂 -
group_replication_single_primary_mode=OFF：这是多主模式的开关，设为 ON 就变单主了
新节点加入集群为什么一直卡在 RECOVERING 状态？
常见原因是 log_slave_updates=1 没开，或 relay_log_info_repository=TABLE 和 master_info_repository=TABLE 配置缺失。MGR 新节点加入后，会先以异步复制方式从 donor 节点拉取缺失 binlog，这个过程依赖标准复制通道——如果没开 log_slave_updates，donor 节点自身的 binlog 就不会记录 relay log 回放产生的事件，新节点永远追不齐。
- 检查 donor 节点是否真在运行
group_replication，且状态为ONLINE（查SELECT * FROM performance_schema.replication_group_members） - 确认 donor 节点磁盘空间充足，
group_replication_recovery_complete_at=COMMIT（默认值）意味着 recovery 过程中所有事务都得写 relay log，空间不足会静默失败 - 跨机房部署时，
group_replication_compression_threshold建议调高（如 1MB），避免小事务频繁压缩/解压加重 CPU 负担
真正麻烦的不是配置步骤，而是 writeset 冲突暴露的业务逻辑缺陷——它逼你重新审视“哪些数据天然支持并发写”“哪些必须串行化”。MGR 多主不是让你放开写，而是把冲突从最终一致性阶段提前到事务提交瞬间，代价是应用层要更小心地划分写入边界。
