双主架构概述

MySQL双主架构（Dual-Master）是指两个MySQL节点互为主从，任何一台节点均同时承担读写请求，并通过复制机制保持数据最终一致。该架构能在单节点故障时自动切换，实现应用层无感知的容灾能力，适合对可用性要求较高的中小型业务场景。

架构适用场景

双主架构并非万能，建议在以下场景中使用：

• 读写压力可控，允许短暂的数据不一致窗口。
• 需要数据库高可用，但无条件引入复杂中间件。
• 两个节点分属不同机房或机架，希望降低单点风险。

核心配置要点

1. 基础参数设置

两节点需开启binlog，并设置全局唯一server-id。同时建议开启GTID模式，便于复制管理与故障切换。参考配置：

server-id=1
log-bin=mysql-bin
gtid_mode=ON
enforce_gtid_consistency=ON

另一节点将server-id改为2，其余保持一致。

2. 自增冲突规避

为避免双写时主键冲突，应设置自增偏移量与步长。示例：节点A设置auto_increment_offset=1，节点B设置auto_increment_offset=2，两者auto_increment_increment=2。也可根据实际并发度调整步长，确保两节点生成的自增ID永不重复。

3. 双向复制授权

分别在两个节点创建复制专用账号，并授权REPLICATION SLAVE。然后通过CHANGE MASTER TO语句将A指向B，B指向A。操作时注意记录各节点binlog位置，或直接使用GTID自动定位。

4. 启用半同步复制

双主架构中，推荐启用半同步复制插件，确保事务提交后至少有一个从节点接收到binlog，降低数据丢失风险。安装插件并设置：

INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
SET GLOBAL rpl_semi_sync_master_enabled=1;
SET GLOBAL rpl_semi_sync_slave_enabled=1;

故障切换与高可用增强

双主架构本身不具备自动故障转移能力，需配合Keepalived或MHA实现VIP漂移。以Keepalived为例，为两个节点绑定虚拟IP，通过健康检查脚本探测MySQL存活状态，一旦主节点异常，VIP自动漂移至另一节点，应用端连接无需修改。

常见风险与应对

• 双写冲突：业务层应尽量避免对同一行数据进行并发更新，必要时可采用分布式锁或队列串行化。
• 复制中断：定期监控Seconds_Behind_Master，发现主键冲突或binlog丢失时，应立刻暂停写入并修复复制链路。
• 脑裂问题：使用Keepalived时需配置仲裁机制，防止网络抖动导致双VIP同时存在。

总结

MySQL双主架构搭建简单、成本较低，能有效提升数据库层的容灾能力。但双节点同时可写会引入数据一致性风险，必须通过合理的自增配置、复制监控和应用层限制来保证稳定运行。建议在实际生产环境部署前，充分进行故障演练，并结合半同步复制与高可用工具，打造更可靠的双活体系。