MySQL 高可用架构实战：Keepalived 双主复制方案详解

在互联网高并发场景下，数据库的高可用性至关重要。MySQL 作为常用的关系型数据库，其高可用方案有很多，本文将重点介绍一种常见的方案：MySQL+Keepalived 主主复制。这种方案通过主主复制保证数据同步，并通过 Keepalived 实现故障自动切换，确保服务持续可用。

问题场景与挑战

假设我们有一个电商系统，数据库存储了商品信息、订单数据等核心业务数据。如果数据库出现单点故障，会导致整个系统瘫痪，造成巨大的经济损失。因此，我们需要一套高可用方案来保证数据库的稳定运行。

传统的主从复制虽然可以提供一定的冗余，但在主库故障时，需要手动切换到从库，这个过程耗时较长，无法满足高可用需求。而使用 MySQL 集群方案，如 MySQL Cluster 或 Galera Cluster，配置和维护相对复杂。因此，MySQL+Keepalived 主主复制成为一种相对简单且可靠的选择。

底层原理深度剖析

主主复制是指两台 MySQL 服务器互为主库，互相进行数据同步。当一台服务器发生故障时，另一台服务器可以立即接管服务，保证数据不丢失。这种方案的关键在于解决数据冲突问题，因此需要合理的设计和配置。

Keepalived 是一个基于 VRRP 协议的高可用软件，它可以实现服务器的自动故障切换。Keepalived 通过虚拟 IP (VIP) 地址对外提供服务，当主服务器发生故障时，Keepalived 会将 VIP 地址自动切换到备服务器，从而实现服务的平滑切换。Keepalived 的工作原理依赖于心跳检测，定期检查服务器的健康状态。

VRRP 协议本身涉及选举机制，通过优先级来确定主备角色。当优先级高的服务器恢复时，可以配置是否抢占 VIP，以实现自动恢复。

具体代码/配置解决方案

下面是一个简单的 MySQL+Keepalived 主主复制 配置示例：

1. MySQL 配置 (MySQL 1 和 MySQL 2)

# MySQL 1 (server-id = 101)
server-id = 101
log_bin = mysql_bin
binlog_format = ROW # 推荐使用 ROW 格式
replicate_do_db = your_database # 指定需要复制的数据库

# MySQL 2 (server-id = 102)
server-id = 102
log_bin = mysql_bin
binlog_format = ROW
replicate_do_db = your_database

2. Keepalived 配置 (Master Server)

# /etc/keepalived/keepalived.conf
global_defs {
 notification_email {
  your_email@example.com
 }
 notification_email_from keepalived@example.com
 smtp_server smtp.example.com
 smtp_connect_timeout 30
 router_id LVS_DEVEL
}

vrrp_script chk_mysql {
 script "/etc/keepalived/check_mysql.sh"
 interval 2 # 每 2 秒检查一次
 weight 2 # 成功则权重加 2
 fall 2 # 连续两次失败则认为服务故障
 rise 2 # 连续两次成功则认为服务恢复
}

vrrp_instance VI_1 {
 state MASTER # 主服务器
 interface eth0 # 网卡名称
 virtual_router_id 51 # VRID，主备服务器必须一致
 priority 150 # 优先级，主服务器必须高于备服务器
 advert_int 1
 authentication {
  auth_type PASS
  auth_pass your_password
 }
 virtual_ipaddress {
  192.168.1.100 # 虚拟 IP 地址
 }
 track_script {
  chk_mysql
 }
}

3. Keepalived 配置 (Backup Server)

# /etc/keepalived/keepalived.conf
global_defs {
 notification_email {
  your_email@example.com
 }
 notification_email_from keepalived@example.com
 smtp_server smtp.example.com
 smtp_connect_timeout 30
 router_id LVS_DEVEL
}

vrrp_script chk_mysql {
 script "/etc/keepalived/check_mysql.sh"
 interval 2 # 每 2 秒检查一次
 weight 2 # 成功则权重加 2
 fall 2 # 连续两次失败则认为服务故障
 rise 2 # 连续两次成功则认为服务恢复
}

vrrp_instance VI_1 {
 state BACKUP # 备服务器
 interface eth0 # 网卡名称
 virtual_router_id 51 # VRID，主备服务器必须一致
 priority 100 # 优先级，备服务器必须低于主服务器
 advert_int 1
 authentication {
  auth_type PASS
  auth_pass your_password
 }
 virtual_ipaddress {
  192.168.1.100 # 虚拟 IP 地址
 }
 track_script {
  chk_mysql
 }
}

4. MySQL 健康检查脚本 (check_mysql.sh)

#!/bin/bash

mysql -u root -pyour_password -h 127.0.0.1 -e 'show status' > /dev/null 2>&1
if [ $? -eq 0 ]; then
 exit 0 # MySQL 服务正常
else
 exit 1 # MySQL 服务异常
fi

5. 配置 MySQL 主主复制

在 MySQL 1 上执行：

CHANGE MASTER TO
 MASTER_HOST='MySQL 2 IP',
 MASTER_USER='repl',
 MASTER_PASSWORD='your_password',
 MASTER_LOG_FILE='mysql-bin.000001', -- 根据实际情况调整
 MASTER_LOG_POS=4; -- 根据实际情况调整
START SLAVE;

在 MySQL 2 上执行：

CHANGE MASTER TO
 MASTER_HOST='MySQL 1 IP',
 MASTER_USER='repl',
 MASTER_PASSWORD='your_password',
 MASTER_LOG_FILE='mysql-bin.000001', -- 根据实际情况调整
 MASTER_LOG_POS=4; -- 根据实际情况调整
START SLAVE;

实战避坑经验总结

• 数据冲突问题： 由于是主主复制，需要特别注意数据冲突问题。例如，自增 ID 可能重复。常见的解决方案是设置不同的起始值和步长，或者使用 UUID 等全局唯一 ID。
• binlog 格式： 推荐使用 ROW 格式，可以避免语句复制带来的问题。
• VIP 切换延迟： Keepalived 的切换时间受到心跳间隔和检测次数的影响。可以适当调整这些参数，以降低切换延迟。但要注意，过短的间隔可能会导致误判。
• 脑裂问题： 在网络不稳定时，可能会出现脑裂问题，即两台服务器都认为自己是主服务器。可以使用仲裁机制，例如引入第三方监控，来避免脑裂。
• 权限配置： 确保 Keepalived 进程有足够的权限执行健康检查脚本，以及访问 MySQL 服务。可以使用 chmod +x 命令给脚本添加执行权限。
• 监控告警： 建立完善的监控告警体系，及时发现并处理故障。可以使用 Prometheus + Grafana 等工具进行监控。

此外，在实际生产环境中，可以考虑使用 LVS 或 Nginx 作为负载均衡器，将流量分发到不同的 MySQL 服务器，进一步提高系统的可用性和性能。 同时也要关注如数据库连接池配置 (如 HikariCP) 中最大连接数设置，避免因连接数耗尽导致服务不可用。以及慢查询优化，使用如 pt-query-digest 工具分析慢查询日志。 还可以配合宝塔面板等可视化工具，方便管理 MySQL 和 Keepalived 服务。