MySQL 多主复制需借助 GTID 双主、MGR 或多分片中间件实现，原生不支持真多主；GTID 双主须约定写规则并避 AUTO_INCREMENT 冲突；MGR 多主模式需关单主模式、用 ROW 格式及显式主键，写冲突会回滚；中间件方案通过分片路由实现逻辑多主，但限制 SQL 兼容性；部署须规避时间戳冲突、DDL 同步风险与环形复制。
MySQL 多主复制（Multi-Master Replication）指多个 MySQL 实例均可接受写入，并将各自变更同步到其他节点，实现读写扩展与高可用。但原生 MySQL 不直接支持“真多主”（如三个节点任意写互不冲突），需借助特定方案规避冲突、保证数据一致性。
基于 GTID + 循环复制的双主架构
这是最常用、相对稳定的“类多主”方案，适用于两个节点互为备份、读写分离场景：
- 两台 MySQL 实例（Server A 和 Server B）互相配置为对方的从库，启用 GTID（全局事务标识），避免位点错乱
- 必须约定写入规则：例如应用层控制，只往一个主写（如 A 写、B 只读 + 备用），或按业务分片（用户 ID 奇数写 A、偶数写 B）
- 禁用
AUTO_INCREMENT冲突：在 A 设置auto_increment_offset=1、auto_increment_increment=2；B 设置为offset=2、increment=2 - 开启
log_slave_updates，确保中继日志能继续向下游转发
使用 MySQL Group Replication（MGR）实现多主模式
MGR 是 MySQL 官方提供的插件式高可用方案，支持单主（default）和多主（multi-primary）模式，后者允许多节点同时写入：
- 启用 multi-primary 模式需在所有节点配置：
group_replication_single_primary_mode=OFF - 所有节点必须使用 ROW 格式二进制日志、GTID、innodb 引擎，且表必须有显式主键
- 写冲突会触发事务回滚（如两个节点同时更新同一行），应用需捕获
ER_GROUP_REPLICATION_CONSISTENCY_ERROR并重试 - 注意：MGR 多主模式对网络延迟敏感，不推荐跨机房部署；建议控制在 3–5 节点内
借助第三方中间件实现逻辑多主（如 DBProxy / MyCat / Vitess）
这类方案不在数据库层做复制协调，而是由中间件解析 SQL、路由 写请求到不同分片，再通过单向复制或异步同步补全数据：
- 适合超大规模写入场景，如按用户 ID 或订单号哈希分片，每个分片是独立主从结构
- 中间件负责规避跨分片事务（通常不支持分布式事务）、处理读写分离、故障自动切换
- 缺点是强依赖中间件稳定性，SQL 兼容性受限（如部分 JOIN、子查询可能无法下推）
- 典型组合：Vitess + MySQL 主从集群，可模拟出“无限水平扩展”的多主效果
关键注意事项与避坑提醒
无论采用哪种方式，“多主”本质是在可用性、一致性、复杂度之间权衡，以下几点极易出问题：
- 时间戳 /UUID 冲突：避免用
NOW()或SYSDATE()作为唯一业务字段；推荐用REPLACE INTO或INSERT …… ON DUPLICATE KEY UPDATE替代单纯 INSERT - DDL 同步风险：MGR 中 DDL 默认阻塞整个组；双主架构中 DDL 必须在所有节点顺序执行，否则易导致复制中断
- 监控不可少：重点盯
seconds_behind_master、group_replication_members状态、show slave statusG中的Retrieved_Gtid_Set与Executed_Gtid_Set是否一致 - 不要盲目上三主以上原生双主环：A→B→C→A 的环形复制极易因单点延迟引发级联延迟甚至死锁，生产环境极少采用
不复杂但容易忽略。选型时优先考虑 MGR（5.7.17+ / 8.0+）或多分片中间件方案，慎用手工搭建的多环主复制。
