三台MySQL服务器Keepalived VIP高可用方案

最常见的场景是：手头拥有三台 MySQL 服务器，例如一主两备架构，希望通过 Keepalived 实现 VIP 漂移，确保应用始终能够连接到主库。具体如何配置？接下来直接看操作细节。

下面提供一套可直接部署的方案，包含环境假设、配置示例、脚本以及重要注意事项。

1. 环境假设

VIP 地址为 192.168.100.100/24，网卡接口使用 eth0，实际部署时请根据自身环境调整。

2. Keepalived 配置

server1（主库，优先级最高）

vrrp_script chk_mysql {    script "/etc/keepalived/check_mysql.sh"    interval 2    weight -20}vrrp_instance VI_1 {    state BACKUP               # 所有节点都用 BACKUP    nopreempt                  # 关闭抢占    interface eth0    virtual_router_id 51    priority 100               # 最高，初始为主    advert_int 1    authentication {        auth_type PASS        auth_pass 1111    }    virtual_ipaddress {        192.168.100.100/24    }    track_script {        chk_mysql    }}

server2（备库1）

vrrp_script chk_mysql {    script "/etc/keepalived/check_mysql.sh"    interval 2    weight -20}vrrp_instance VI_1 {    state BACKUP    nopreempt    interface eth0    virtual_router_id 51    priority 90    advert_int 1    authentication {        auth_type PASS        auth_pass 1111    }    virtual_ipaddress {        192.168.100.100/24    }    track_script {        chk_mysql    }}

server3（备库2）

vrrp_script chk_mysql {    script "/etc/keepalived/check_mysql.sh"    interval 2    weight -20}vrrp_instance VI_1 {    state BACKUP    nopreempt    interface eth0    virtual_router_id 51    priority 80    advert_int 1    authentication {        auth_type PASS        auth_pass 1111    }    virtual_ipaddress {        192.168.100.100/24    }    track_script {        chk_mysql    }}

3. 工作逻辑

正常情况下，VIP 会绑定在 server1 上，应用通过 VIP 连接主库。一旦 server1 发生故障，Keepalived 检测到异常后，VIP 会自动漂移到优先级次高的 server2。此时有一个关键步骤：server2 必须先提升为 MySQL 主库，执行 STOP SLA VE; RESET SLA VE ALL;，否则应用会连接到只读备库，无法写入数据。

当 server1 恢复后，如果配置了 state MASTER 和较高的 priority，VIP 会自动抢占回来。若希望避免自动抢占，可以设置 nopreempt，并将所有节点的状态都设为 BACKUP。

4. 与 MySQL 故障切换的配合

Keepalived 仅负责 IP 漂移，MySQL 的角色切换需要自行处理。核心思路是：确保 VIP 所在的服务器始终是允许写入的 MySQL 主库。

因此需要编写监测脚本，让 Keepalived 判断本机是否为主库，再决定是否持有 VIP。即使优先级很高，如果本机不是主库，也必须释放 VIP。

4.1 编写检测脚本（在所有节点）

/etc/keepalived/check_mysql.sh：

#!/bin/bash# 检查本机 MySQL 是否可写（即当前不是只读的备库）mysql -u root -p'你的密码' -e "SELECT 1;" &>/dev/nullif [ $? -ne 0 ]; then    exit 1   # 连接失败，释放 VIPfi# 检查 read_only 是否为 OFF（主库才可写）READ_ONLY=$(mysql -u root -p'你的密码' -e "SHOW VARIABLES LIKE 'read_only';" | grep -c "OFF")if [ $READ_ONLY -eq 1 ]; then    exit 0   # 是主库，可以持有 VIPelse    exit 1   # 是只读备库，释放 VIPfi

chmod +x /etc/keepalived/check_mysql.sh

4.2 在 Keepalived 配置中调用检测脚本

在每个节点的 keepalived.conf 的 vrrp_instance 段内添加：

track_script {    chk_mysql}

并在全局部分定义脚本：

vrrp_script chk_mysql {    script "/etc/keepalived/check_mysql.sh"    interval 2          # 每 2 秒检查一次    weight -20          # 失败时降低优先级 20，确保 VIP 被其他节点接管}

注意：weight 的绝对值必须大于最高优先级与其他节点的差值。例如优先级差值为 10，这里设为 -20 可确保一旦本机不是主库，VIP 就会漂移。

手动切换后的流程：当需要主动切换（如运维维护）时，先在新主库上执行 STOP SLA VE; RESET SLA VE ALL;，并确认 read_only=OFF。然后在原主库上手动停止 Keepalived 或降低其 priority，VIP 会自动漂移到新主库。应用无需更改任何连接信息。

5. 注意事项

所有节点的 Keepalived 配置中 virtual_router_id 必须一致（同一组 VRRP）。确保 authentication 密码一致。防火墙需放行 VRRP 协议：firewall-cmd --add-protocol=vrrp --permanent; firewall-cmd --reload。VIP 必须与实际网卡同网段，且未被其他设备占用。检测脚本中的数据库密码需妥善保管，可限制权限文件读取。

6. 测试方法

在主库上查看 VIP：

ip addr show eth0 | grep 192.168.100.100

应能看到 VIP。然后停止主库 MySQL 或 Keepalived，观察 VIP 是否漂移到优先级最高的备库。在备库上提升为可写主库后，检查 read_only 状态，应用应能正常连接 VIP 写入。