keepalived健康检查脚本必须返回0或1以触发vip漂移，不能直接停服务；应使用mysql命令验证查询能力，配合track_script、fall/rise参数及正确网络配置确保故障时vip及时切换。
Keepalived健康检查脚本没生效，VIP卡在故障主库上
这是最常见也最致命的问题：MySQL进程已僵死，但Keepalived仍认为主库“活着”，VIP不漂移。根本原因在于默认的vrrp_script只检查进程是否存在，不验证MySQL能否真正响应查询。
必须用能反映服务真实可用性的检测逻辑，比如：
- 用
mysql -h127.0.0.1 -P3306 -uhealth_check -p'xxx' -e "SELECT 1"执行轻量查询，而非仅pgrep mysqld - 脚本返回值必须严格：成功时
exit 0，失败时exit 1（任何非0都算失败） - 在
vrrp_instance中用track_script绑定该脚本，并设置fall 3（连续3次失败才降权）和rise 2（连续2次成功才升权）
Keepalived配置里MASTER/BACKUP角色切换失败
VRRP选举失败通常不是因为优先级数字写错，而是网络层没通或权限被拦。
重点检查这几项：
-
interface必须填物理网卡名（如eth0），不能填lo或别名（如eth0:1） - 两台机器的
vrrp_instance VI_1中，virtual_router_id必须完全一致（范围1–255），且同一局域网内不能重复 - 防火墙要放行VRRP组播包：
iptables -A INPUT -d 224.0.0.18 -j ACCEPT（CentOS 7+还需firewall-cmd --add-masquerade） - 如果用云服务器（如阿里云、AWS），默认禁用组播和非ARP广播，VIP漂移会彻底失效——必须改用单播模式或换自建IDC
MHA环境下VIP漂移脚本权限或路径出错
MHA本身不管理VIP，靠master_ip_failover_script调用外部脚本完成绑定/解绑。这里踩坑最多的是环境隔离问题。
实操要点：
- 脚本路径必须在MHA配置文件
app1.cnf中用绝对路径写死：master_ip_failover_script=/service/mha/master_ip_failover - 脚本开头加
#!/usr/bin/perl（MHA官方脚本是Perl写的），并确保perl在PATH中；若改用Shell，第一行换成#!/bin/bash，且所有命令用绝对路径（如/sbin/ifconfig而非ifconfig） - 脚本里
$ssh_start_vip和$ssh_stop_vip中的网卡名（如eth1）、子接口编号（如:1）、子网掩码（如/24）必须和实际环境严丝合缝 - 运行MHA Manager的用户（如
mha）必须对脚本有+x权限，且能免密SSH到所有MySQL节点执行ifconfig
VIP漂移后客户端连不上新主库
VIP虽然成功绑到新主库，但业务仍报“Connection refused”或超时，大概率是MySQL监听配置没跟上。
关键检查点：
- MySQL的
bind_address不能设为127.0.0.1，得是0.0.0.0或具体网卡IP（如192.168.4.52），否则VIP流量进不来 - 确认新主库的
skip_networking是OFF（默认就是OFF，但有些安全加固脚本会误开） - 切换后立刻在新主库上执行
show variables like 'read_only';——必须是OFF，否则应用写请求会被拒绝 - ARP缓存刷新可能延迟，客户端本地执行
arp -d <code>192.168.4.100强制清掉旧MAC映射
ip addr show里VIP在哪，得盯着mysql -h192.168.4.100 -e "SELECT @@hostname"能不能立刻返回新主库名。
