17370845950

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 status\G 中的 Retrieved_Gtid_Set 与 Executed_Gtid_Set 是否一致
• 不要盲目上三主以上原生双主环：A→B→C→A 的环形复制极易因单点延迟引发级联延迟甚至死锁，生产环境极少采用

不复杂但容易忽略。选型时优先考虑 MGR（5.7.17+ / 8.0+）或多分片中间件方案，慎用手工搭建的多环主复制。