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 status\G中的
Retrieved_Gtid_Set与
Executed_Gtid_Set是否一致 不要盲目上三主以上原生双主环：A→B→C→A 的环形复制极易因单点延迟引发级联延迟甚至死锁，生产环境极少采用
不复杂但容易忽略。选型时优先考虑 MGR（5.7.17+ / 8.0+）或多分片中间件方案，慎用手工搭建的多环主复制。
