最常见的场景是：手头拥有三台 MySQL 服务器，例如一主两备架构，希望通过 Keepalived 实现 VIP 漂移，确保应用始终能够连接到主库。具体如何配置？接下来直接看操作细节。
下面提供一套可直接部署的方案，包含环境假设、配置示例、脚本以及重要注意事项。
1. 环境假设
| 主机 | IP | MySQL 角色 | Keepalived 角色 | priority |
|---|---|---|---|---|
| server1 | 192.168.100.1 | 当前主库 | MASTER | 100 |
| server2 | 192.168.100.2 | 备库1 | BACKUP | 90 |
| server3 | 192.168.100.3 | 备库2 | BACKUP | 80 |
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 写入。
