当你有三台 MySQL 服务器（例如一主两备），可以使用 Keepalived 实现 VIP 漂移，始终让 VIP 指向当前的主库。
以下给出一主两备场景下的 Keepalived 配置方案，并说明与 MySQL 复制的配合。
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（90 > 80）。
此时 server2 必须先被提升为 MySQL 主库（STOP SLAVE; RESET SLAVE ALL;），否则应用会连到只读备库。
server1 恢复：由于设置 state MASTER 和较高 priority，VIP 会抢占回 server1（若原主库已恢复且需要重新作为主库）。
如果不想自动抢占，可以设置 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/null
if [ $? -ne 0 ]; then
exit 1 # 连接失败，释放 VIP
fi
检查 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 # 是主库，可以持有 VIP
else
exit 1 # 是只读备库，释放 VIP
fi
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 的绝对值应大于最高优先级与其他节点的差值。例如 priority 差值为 10，这里设 -20 可确保一旦本机不是主库，VIP 就会漂移。
. 手动切换后的流程
当需要主动切换（如维护）时：
在新主库上执行 STOP SLAVE; RESET SLAVE 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 写入。
