mysql多主模式需满足版本≥5.7.17、gtid开启、row格式binlog、唯一server-id、innodb引擎及显式主键等硬性条件，并严格配置group_replication_single_primary_mode=off、enforce_update_everywhere_checks=on等参数，启动须按bootstrap→关闭→加入顺序执行，且依赖写集冲突检测机制，应用层需处理事务回滚与重试。
多主模式不是开个开关就能用的，它要求所有节点都可写、必须严格规避冲突、且配置稍有偏差就会启动失败或数据错乱。
确认 MySQL 版本与基础环境是否达标
MySQL 5.7.17+ 或 8.0.x 是硬性门槛，低于这个版本压根没 group_replication 插件。你得先验证：
-
SELECT VERSION();确保输出是5.7.17或更高（比如8.0.33） - 所有节点必须启用
gtid_mode=ON和enforce_gtid_consistency=ON -
binlog_format必须为ROW，binlog_checksum必须设为NONE - 每个节点的
server_id必须唯一，且不能为 0 或重复 - 表必须用
InnoDB引擎，且每张可写表必须有显式主键或非 NULL 唯一键
关键参数：多主模式专属配置项
单主模式下 group_replication_single_primary_mode=ON 是默认值；切多主，必须显式关掉它，并打开冲突检测支持：
- 在所有节点的
my.cnf中添加：group_replication_single_primary_mode=OFFgroup_replication_enforce_update_everywhere_checks=ON -
group_replication_bootstrap_group=OFF（仅首次启动主节点时临时设为ON，之后立即关掉） - 确保
group_replication_group_name在所有节点完全一致，格式必须是标准 UUID（如"aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"） -
group_replication_ip_allowlist要显式列出所有节点 IP，不能留空或写0.0.0.0/0（MGR 8.0.24+ 默认拒绝）
启动顺序与常见卡点
多主模式不能像单主那样先启主再加从——所有节点必须“同时”完成初始化并加入组，否则会因状态不一致被拒绝：
- 第一步：在任意一个节点执行
SET GLOBAL group_replication_bootstrap_group=ON;，再执行START GROUP_REPLICATION; - 第二步：立刻在该节点执行
SET GLOBAL group_replication_bootstrap_group=OFF;（这步漏掉会导致后续节点无法加入） - 第三步：其他节点直接执行
START GROUP_REPLICATION;，不要设bootstrap_group - 如果卡在
RECOVERING状态超过 2 分钟，大概率是网络延迟高、group_replication_recovery_complete_at_timeout默认值（60 秒）不够，需调大 - 查状态统一用
SELECT * FROM performance_schema.replication_group_members;，看到全部STATE = ONLINE才算成功
写入冲突：多主最真实的“拦路虎”
MGR 多主不是无脑允许多点写，它靠写集（write set）做冲突检测——同一行被两个节点并发修改，后提交的那个事务会被直接回滚，客户端收到 ERROR 3098 (HY000): The table does not comply with the requirements... 类似错误（实际错误码可能是 3098 或 3100）：
- 冲突检测只发生在主键/唯一键级别，
UPDATE t SET x=1 WHERE id=1和UPDATE t SET y=2 WHERE id=1会被判为冲突（因为写集包含同一行的主键） - 应用层必须捕获这类错误并重试，不能假设“写就一定成功”
- 避免跨节点更新同一张表的同一业务主键范围（比如订单号按奇偶分片到不同节点），这是最稳妥的规避手段
-
SELECT ... FOR UPDATE在多主下无效，MGR 不传播锁，只校验写集
多主模式真正的复杂点不在配置，而在于你得提前想清楚：哪些表允许并发写、哪些必须路由到固定节点、应用是否做好了冲突重试和幂等。参数配对只是起点，业务逻辑适配才是落地门槛。
