MySQL 高可用架构：Keepalived 双主热备实战与原理剖析

etqdffeb

132人浏览 · 2026-05-13 18:06:44

etqdffeb · 2026-05-13 18:06:44 发布

构建高可用的 MySQL 数据库集群是现代应用架构的关键一环。传统的 MySQL 主从复制在主节点故障时需要手动切换，存在服务中断的风险。双主复制旨在解决这个问题，让两个 MySQL 实例互为主备，提升整体的可用性。而 Keepalived 则作为保障双主切换平滑、自动化的重要组件，其核心在于VRRP协议，能够有效监控MySQL服务器的状态，并在发生故障时自动切换VIP。

然而，直接采用双主复制也面临诸多挑战，比如数据一致性问题、脑裂问题等。我们需要精细的配置和监控，才能确保系统的稳定运行。这也是为什么 Keepalived MySQL 双主复制成为了一个经典但需要谨慎使用的组合。

问题背景与需求分析

在很多高并发、高可用的互联网应用场景中，例如电商、金融系统，数据库的稳定运行至关重要。如果单点 MySQL 故障，会导致整个服务瘫痪，造成严重的经济损失和用户体验下降。因此，我们需要一种能够自动切换、快速恢复的 MySQL 高可用方案。传统的方案可能依赖于人工干预，响应速度慢，无法满足需求。而 MySQL Keepalived 主主复制方案，能够通过自动化的 VIP 漂移，实现故障的快速切换，将停机时间降到最低。

Keepalived MySQL 双主复制的原理与配置详解

Keepalived 的工作原理基于 VRRP (Virtual Router Redundancy Protocol) 协议，通过虚拟 IP (VIP) 实现服务的平滑切换。在 MySQL 双主复制环境中，两个 MySQL 实例分别运行在两台服务器上，同时监听各自的 IP 地址，并配置为互相同步数据。Keepalived 负责监控 MySQL 的运行状态，并在其中一台服务器发生故障时，自动将 VIP 切换到另一台服务器，从而保证服务的连续性。

VRRP 协议与 Keepalived 配置

VRRP 协议的核心概念包括：

Virtual Router ID (VRID)：虚拟路由器的 ID，用于区分不同的 VRRP 实例。
Priority：优先级，用于确定哪个节点成为 Master 节点。优先级高的节点优先成为 Master。
Virtual IP Address (VIP)：虚拟 IP 地址，客户端通过 VIP 访问 MySQL 服务。当 Master 节点故障时，VIP 会自动漂移到 Backup 节点。

以下是一个简化的 Keepalived 配置文件示例：

! Configuration File for keepalivedglobal_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/mysql_check.sh" #MySQL 状态检测脚本 interval 2 #检测间隔 weight -2 #检测失败权重 fall 2 #检测失败几次切换状态 rise 1 #检测成功几次恢复状态}vrrp_instance VI_1 { state BACKUP #初始状态备份 interface eth0 #网卡名称 virtual_router_id 51 #VRID priority 100 #优先级，主服务器更高 advert_int 1 authentication {  auth_type PASS  auth_pass 1111 } virtual_ipaddress {  192.168.1.100 #VIP地址 } track_script {  chk_mysql }}

注意： 上述配置需要根据实际情况进行调整，例如网卡名称、VIP 地址、邮箱地址、MySQL 状态检测脚本路径等。

MySQL 双主复制配置

MySQL 双主复制的配置相对复杂，需要保证两个 MySQL 实例的数据一致性。需要配置 binlog 和 gtid，才能保证数据同步的可靠性。

# server-id 必须不同，例如 server-id=1 和 server-id=2server-id=1log_bin=mysql-bin # 开启 binlogbinlog_format=ROW # 建议使用 ROW 格式relay_log=relay-loggtid_mode=ON # 开启 GTIDenforce_gtid_consistency=ONlog_slave_updates=ON # 从服务器也要记录 binlog#主库配置如下server-id=1log_bin=mysql-bin # 开启 binlogbinlog_format=ROW # 建议使用 ROW 格式relay_log=relay-loggtid_mode=ON # 开启 GTIDenforce_gtid_consistency=ONlog_slave_updates=ON # 从服务器也要记录 binlogbinlog_checksum=CRC32binlog_cache_size=512Mbinlog_stmt_cache_size=512Msync_binlog=1

需要注意设置server-id,在主从节点上不能相同。

实战避坑经验与总结

在实际部署 MySQL Keepalived 主主复制方案时，需要注意以下几点：

脑裂问题：脑裂是指两个 MySQL 实例都认为自己是 Master，导致数据冲突。可以通过配置合适的仲裁机制，例如使用 ZooKeeper 或 etcd，来避免脑裂问题。
数据一致性：确保两个 MySQL 实例的数据一致性至关重要。建议使用 GTID 复制，并定期进行数据校验。
监控与告警：建立完善的监控体系，监控 MySQL 的运行状态、复制状态、以及 Keepalived 的状态。设置告警阈值，及时发现并处理问题。
切换演练：定期进行切换演练，模拟故障场景，验证系统的可用性，并熟悉切换流程。
MySQL 状态检测脚本：mysql_check.sh 脚本需要根据具体情况进行调整，确保能够准确判断 MySQL 的运行状态。例如，可以检测 MySQL 的连接数、查询响应时间等。

总之，MySQL Keepalived 主主复制方案是一个强大的高可用解决方案，但需要精心的配置和维护。只有深入理解其原理，并结合实际场景进行优化，才能充分发挥其价值，保障数据库的稳定运行。