如何基于Keepalived实现MySQL双机高可用HA架构？

在现代企业级应用架构中，数据库的稳定性直接决定了业务的连续性。MySQL作为最流行的开源关系型数据库，常常承载着核心交易数据。然而单节点MySQL一旦发生宕机，整个系统将面临不可用的风险。为了消除单点故障，引入高可用（HA）架构势在必行。Keepalived凭借其轻量级和高效的VRRP协议实现，成为构建MySQL双机热备的首选方案。通过浮动虚拟IP地址，Keepalived能够在主节点故障时将流量自动切换至备用节点，从而实现业务的平滑过渡。

Keepalived与VRRP协议的核心原理

Keepalived的核心基础是VRRP（Virtual Router Redundancy Protocol，虚拟路由冗余协议）。在双机HA架构中，两台MySQL服务器会被划分为Master和Backup角色。它们对外暴露的并非各自的物理IP，而是一个由Keepalived维护的虚拟IP（VIP）。客户端应用只需连接这个VIP，无需关心实际处理请求的是哪台物理机。这种解耦设计使得底层的故障切换对应用层完全透明。

VRRP协议通过组播方式在主备节点之间发送心跳包。正常情况下，Master节点周期性地发送VRRP通告报文，Backup节点接收到通告后认为Master处于正常状态。当Master发生硬件宕机或网络中断无法发送通告时，Backup节点在等待一定时间后收不到通告，会根据优先级参数计算出新的Master，并将VIP漂移至自身网卡上。这个过程非常迅速，通常只需几秒钟即可完成。

除了网络层面的故障检测，Keepalived还支持通过执行自定义脚本来进行应用层健康检查。对于MySQL而言，仅仅网络可达并不代表数据库可用。我们需要编写检测脚本，定期检查MySQL的连通性、主从同步状态等。一旦检测失败，Keepalived会主动降低当前节点的优先级，从而触发VIP的转移。这种机制确保了只有真正健康的节点才能持有VIP并对外提供服务。

MySQL双机主从复制环境搭建

Keepalived只负责IP层面的漂移，它本身不负责数据的同步。因此，在配置Keepalived之前，必须先完成MySQL的双机主从复制配置。通常采用主从架构，即一台作为主库负责读写，另一台作为从库负责只读和备份。当主库宕机后，VIP漂移到从库，应用继续连接VIP，此时从库接管读写服务。为了保证切换后数据的一致性，主从复制必须采用半同步或者强一致性方案。

在主库的配置文件中，需要开启二进制日志并设置唯一的server-id。二进制日志是主从复制的基础，从库通过读取主库的日志来重放数据变更。同时建议配置binlog_format=ROW，以保证复制的最大可靠性。在从库节点，同样需要配置唯一的server-id，并配置中继日志。建立复制关系时，需要在从库上执行CHANGE MASTER TO语句，指定主库的IP、端口、复制账号以及日志偏移量。

以下是主库配置文件的关键参数示例。在实际部署中，需要根据服务器的硬件配置和网络环境调整缓冲区大小等参数。配置完成后，务必创建一个专门用于复制的最小权限账号，仅授予REPLICATION SLAVE权限，以提升系统安全性。

[mysqld]
server-id=1
log-bin=mysql-bin
binlog_format=ROW
sync_binlog=1
innodb_flush_log_at_trx_commit=1
# 设置复制账号的权限
# CREATE USER 'repl'@'192.168.1.%' IDENTIFIED BY 'password';
# GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.%';

Keepalived配置与故障检测脚本实现

实现MySQL高可用的关键在于如何精准判断数据库的健康状态。Keepalived配置文件通常位于/etc/keepalived/keepalived.conf。配置文件分为全局定义和VRRP实例定义两部分。在VRRP实例中，我们需要指定状态、接口、虚拟路由ID、优先级以及认证信息。主备节点的配置基本一致，唯一的区别在于初始状态和优先级参数。

为了实现应用层检测，必须在VRRP实例中引入track_script模块。这个模块会周期性地调用我们编写的shell脚本。脚本的设计逻辑非常关键：如果MySQL服务停止，或者主从复制中断，脚本应当返回非0值。Keepalived一旦捕获到非0返回值，就会将当前节点的优先级减去一个设定的权重值，导致其优先级低于备用节点，从而触发VIP切换。

检测脚本通常会使用mysqladmin ping或者直接通过mysql客户端执行一条简单的查询。为了防止脑裂现象，还可以在脚本中加入对网关的ping检测。如果当前节点连网关都ping不通，说明网络可能异常，此时也应该主动降级。以下是Keepalived的核心配置示例和检测脚本示例。

vrrp_script chk_mysql {
    script "/etc/keepalived/check_mysql.sh"
    interval 2
    weight -20
    fall 2
    rise 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    track_script {
        chk_mysql
    }
    virtual_ipaddress {
        192.168.1.100
    }
}

#!/bin/bash
MYSQL_HOST=127.0.0.1
MYSQL_PORT=3306
MYSQL_USER=root
MYSQL_PASSWORD=123456

# 检查MySQL是否响应
mysqladmin -h $MYSQL_HOST -P $MYSQL_PORT -u $MYSQL_USER -p$MYSQL_PASSWORD ping > /dev/null 2>&1
if [ $? -ne 0 ]; then
    echo "MySQL is down"
    exit 1
fi

# 检查主从同步状态 (如果是备库)
SLAVE_STATUS=$(mysql -h $MYSQL_HOST -P $MYSQL_PORT -u $MYSQL_USER -p$MYSQL_PASSWORD -e "SHOW SLAVE STATUS\G" 2>/dev/null)
IO_RUNNING=$(echo "$SLAVE_STATUS" | grep "Slave_IO_Running:" | awk '{print $2}')
SQL_RUNNING=$(echo "$SLAVE_STATUS" | grep "Slave_SQL_Running:" | awk '{print $2}')

if [ "$IO_RUNNING" != "Yes" ] || [ "$SQL_RUNNING" != "Yes" ]; then
    echo "Replication is broken"
    exit 1
fi

exit 0

高可用集群的测试与优化建议

配置完成后，必须进行严格的故障演练。常见的测试场景包括：强制停止主库的MySQL服务、重启主库服务器、断开主库网络等。在停止主库MySQL服务后，观察Keepalived日志，应当能看到优先级降低和VIP漂移的记录。此时在备用节点上使用ip addr命令，应该能够看到VIP已经绑定在网卡上。应用端应当能够在短暂超时后自动恢复连接，无需人工干预。

在双机HA架构中，脑裂是最需要防范的风险。当主备节点之间的心跳网络中断，但主节点仍然正常运行时，备节点会认为主节点宕机，从而抢占VIP。这导致主备节点同时持有VIP，引发数据写入冲突。为了缓解脑裂，可以通过增加冗余心跳链路、使用串口线路或者通过仲裁磁盘等方式来提升检测的准确性。同时，在脚本中加入对网关的连通性检测也是一种有效的辅助手段。

此外，当原主节点恢复时，如何处理数据同步也是一个痛点。如果原主节点直接抢回VIP，可能会导致未同步的数据丢失。通常建议采用非抢占模式，即原主节点恢复后，保持Backup状态，直到当前主节点再次故障。运维人员需要手动确认数据一致性后，再决定是否进行角色切换。这种策略虽然增加了人工干预的成本，但最大程度保障了数据安全。

MySQL双机高可用KeepalivedHA架构修改时间：2026-08-27 07:15:24