MySQL双主架构配置与高可用实践指南

1. 为什么需要MySQL双主架构？

在传统的MySQL主从架构中，主节点负责所有写操作，从节点只负责读操作。这种架构虽然简单，但存在单点故障风险。当主节点宕机时，虽然可以手动将从节点提升为主节点，但这个过程需要人工干预，且存在数据丢失的风险。

双主架构（Master-Master）通过让两个节点互为主从，实现了写操作的分布式处理。这种架构的主要优势包括：

• 高可用性：任一节点故障时，另一个节点可以继续提供服务
• 负载均衡：写操作可以分散到两个节点上
• 灾备能力：两个节点可以部署在不同机房，实现异地容灾

注意：双主架构虽然提供了更高的可用性，但也带来了更复杂的数据一致性问题。在决定使用双主架构前，需要评估业务对数据一致性的要求。

2. 双主架构的核心配置要点

2.1 服务器ID配置

每个MySQL实例必须有一个唯一的server-id。在双主架构中，两个节点的server-id必须不同：

ini复制# 节点A配置
server-id=1

# 节点B配置
server-id=2

这个配置需要在my.cnf文件中设置，并重启MySQL服务生效。

2.2 自增ID处理

在双主架构中，两个节点都可能生成自增ID。为了避免ID冲突，需要配置不同的自增起始值和步长：

ini复制# 节点A配置
auto_increment_offset=1
auto_increment_increment=2

# 节点B配置
auto_increment_offset=2
auto_increment_increment=2

这样配置后：

• 节点A生成的ID序列：1, 3, 5, 7...
• 节点B生成的ID序列：2, 4, 6, 8...

2.3 GTID配置

全局事务标识符(GTID)可以简化复制配置和故障恢复。建议在双主架构中启用GTID：

ini复制gtid_mode = ON
enforce_gtid_consistency = 1

3. 详细配置步骤

3.1 修改MySQL配置文件

编辑两个节点的my.cnf文件（通常位于/etc/my.cnf或/etc/mysql/my.cnf）：

节点A配置：

ini复制[mysqld]
server-id=1
log-bin=mysql-bin
binlog-format=ROW
gtid_mode=ON
enforce_gtid_consistency=ON
auto_increment_offset=1
auto_increment_increment=2

节点B配置：

ini复制[mysqld]
server-id=2
log-bin=mysql-bin
binlog-format=ROW
gtid_mode=ON
enforce_gtid_consistency=ON
auto_increment_offset=2
auto_increment_increment=2
read_only=0

修改完成后，重启两个MySQL服务：

bash复制systemctl restart mysql

3.2 创建复制账户

在两个节点上分别创建用于复制的账户：

sql复制CREATE USER 'repl_user'@'%' IDENTIFIED BY 'StrongPassword123!';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
FLUSH PRIVILEGES;

安全提示：请使用强密码替换'StrongPassword123!'，并考虑限制复制账户的访问IP范围。

3.3 配置复制关系

3.3.1 在节点B上配置指向节点A的主从关系

首先在节点A上查看主状态：

sql复制SHOW MASTER STATUS;

记录File和Position值，然后在节点B上执行：

sql复制STOP SLAVE;
CHANGE MASTER TO
MASTER_HOST='节点A的IP',
MASTER_USER='repl_user',
MASTER_PASSWORD='StrongPassword123!',
MASTER_PORT=3306,
MASTER_AUTO_POSITION=1;
START SLAVE;

3.3.2 在节点A上配置指向节点B的主从关系

在节点B上查看主状态：

sql复制SHOW MASTER STATUS;

然后在节点A上执行：

sql复制STOP SLAVE;
CHANGE MASTER TO
MASTER_HOST='节点B的IP',
MASTER_USER='repl_user',
MASTER_PASSWORD='StrongPassword123!',
MASTER_PORT=3306,
MASTER_AUTO_POSITION=1;
START SLAVE;

4. 验证复制状态

在两个节点上分别执行以下命令检查复制状态：

sql复制SHOW SLAVE STATUS\G

重点关注以下字段：

• Slave_IO_Running: Yes
• Slave_SQL_Running: Yes
• Seconds_Behind_Master: 0

如果Seconds_Behind_Master不为0，表示有复制延迟，需要等待其变为0。

5. 常见问题与解决方案

5.1 复制中断问题

问题现象：

code复制Last_IO_Error: error connecting to master...

解决方案：

1. 检查网络连接是否正常
2. 验证复制账户的权限和密码
3. 检查防火墙设置，确保3306端口开放

5.2 数据不一致问题

问题现象：

code复制Last_Error: Could not execute Write_rows event...

解决方案：

1. 停止复制：STOP SLAVE;
2. 跳过错误：SET GLOBAL sql_slave_skip_counter=1; START SLAVE;
3. 对于重要数据，建议手动修复不一致

5.3 自增ID冲突

问题现象：

code复制Duplicate entry 'xxx' for key 'PRIMARY'

解决方案：

1. 检查auto_increment_offset和auto_increment_increment配置是否正确
2. 手动调整冲突的ID值
3. 考虑使用UUID或其他全局唯一标识符替代自增ID

6. 性能优化建议

6.1 网络优化

双主架构对网络延迟敏感，建议：

• 使用专用网络连接
• 确保网络带宽充足
• 对于跨机房部署，考虑使用专线

6.2 参数调优

在my.cnf中添加以下优化参数：

ini复制sync_binlog=1
innodb_flush_log_at_trx_commit=1
slave_parallel_workers=4
slave_parallel_type=LOGICAL_CLOCK

6.3 监控设置

建议监控以下指标：

• 复制延迟时间
• 网络延迟
• 节点负载
• 磁盘I/O

可以使用Prometheus+Grafana或Percona Monitoring and Management等工具进行监控。

7. 维护与故障处理

7.1 日常维护

1. 定期检查复制状态
2. 监控服务器资源使用情况
3. 定期备份数据

7.2 主节点切换

当需要维护一个节点时：

1. 将应用连接切换到另一个节点
2. 停止待维护节点上的复制
3. 执行维护操作
4. 重新启动复制
5. 验证数据一致性

7.3 灾难恢复

当两个节点都出现故障时：

1. 选择数据较新的节点作为新主节点
2. 从备份恢复数据
3. 重新配置复制关系
4. 逐步恢复应用连接

8. 实际应用中的注意事项

1. 写冲突问题：双主架构中，如果两个节点同时修改同一行数据，会导致复制冲突。建议：

   • 应用层实现写操作的路由
   • 按业务功能划分写操作

2. 数据一致性检查：定期使用pt-table-checksum等工具检查数据一致性

3. 负载均衡策略：

   • 读操作可以均匀分配到两个节点
   • 写操作建议固定到一个节点，或按表/业务划分

4. 版本兼容性：确保两个节点的MySQL版本兼容，建议使用相同版本

5. 备份策略：虽然双主架构提供了冗余，但仍需要定期备份

我在实际生产环境中部署双主架构时，发现以下几个经验点特别重要：

• 在业务低峰期进行架构切换
• 切换前确保有完整的备份
• 详细记录每个操作步骤
• 准备回滚方案
• 切换后密切监控系统表现

双主架构虽然复杂，但正确配置和维护后，可以显著提高系统的可用性和可靠性。关键是要理解其工作原理，并针对具体业务需求进行适当调整。