Keepalived 启动后 vip 不飘、ip addr show 看不到虚拟 IP
核心原因通常是 Keepalived 没有获得绑定 VIP 所需的 NET_ADMIN 权限，或 SELinux / firewalld 干预了网络接口操作。
- 检查是否启用非 root 用户运行：
keepalived默认需要cap_net_admin能力，若用普通用户启动（如keepalived -f /etc/keepalived/keepalived.conf -u keepalived），必须显式授予权限：sudo setcap cap_net_admin+ep /usr/sbin/keepalived - SELinux 开启时会拦截
net_admin操作，临时验证可执行：sudo setenforce 0；长期方案是写自定义策略，或改用 permissive 模式配合 audit2allow - firewalld 可能丢弃 VRRP 协议包（目的端口
112，协议112），需放行：sudo firewall-cmd --permanent --add-rich-rule='rule protocol value="112" accept'，然后 reload - 确认网卡名在配置中拼写正确（如
ens33≠eth0），且该网卡处于UP状态：ip link show ens33
MySQL 主从切换后应用连不上 vip，但 ping 和 telnet 都通
常见于 MySQL 绑定地址未包含 vip，或客户端连接池缓存了旧主地址。
- MySQL 必须监听
vip所在网段，不能只写127.0.0.1或具体物理 IP；检查bind-address配置项：设为0.0.0.0或留空（5.7+），并确认skip-networking为OFF - Keepalived 的
notify_master脚本里要触发 MySQL 权限刷新（如mysql -e "FLUSH PRIVILEGES;"），否则新主可能拒绝来自 VIP 的连接（尤其当user@'192.168.1.%'这类 host 匹配失效） - 应用侧 JDBC URL 若含
failover参数（如 MySQL Connector/J 的loadBalance或failover），容易绕过 VIP 直连物理 IP；应统一使用jdbc:mysql://vip:3306/db，禁用自动 failover - 连接池（如 HikariCP）默认复用连接，VIP 切换后旧连接仍发往原节点；需设置
connection-test-query=SELECT 1+validation-timeout，或启用keepalive探活
keepalived.conf 中 vrrp_script 检查 MySQL 状态总失败
脚本返回值不被识别、权限不足、路径硬编码错误，是最常导致 VIP 不切换的隐形故障点。
-
vrrp_script要求脚本 exit code 为0表示健康，非0视为异常；但很多 MySQL 检查脚本用mysql -h127.0.0.1 -P3306 -e "SELECT 1"失败时返回1—— 这没问题；但如果加了&& echo ok导致最后一条命令成功，就会永远返回0 - 脚本中避免使用绝对路径依赖（如
/usr/bin/mysql），建议用command -v mysql动态获取，或在脚本开头加PATH=/usr/local/bin:/usr/bin:/bin - Keepalived 子进程默认以
root启动脚本，但若 MySQL 设置了 socket 认证或skip-networking=ON，脚本要用-S /var/lib/mysql/mysql.sock显式指定 socket 路径 - 不要在脚本里 sleep 或调用耗时命令（如
curl查 API），VRRP 检查超时默认仅 1 秒，多次失败即降权；建议单次检查控制在 200ms 内
双主脑裂（split-brain）时 VIP 同时出现在两台机器上
根本原因是心跳检测失效，而优先级和抢占逻辑没兜住。这不是配置错误，而是架构容忍度问题。
- 确保至少两个独立心跳通道：除默认的 VRRP 组播外，务必添加
vrrp_sync_group+track_script基于物理链路（如ping -c1 192.168.1.1 &>/dev/null网关）或磁盘文件（如stat /mnt/shared/health | grep Modify） - 禁用
preempt_delay不等于解决脑裂；更可靠的是用nofailback+ 手动干预，或引入第三方仲裁（如etcd或corosync+pacemaker），但 Keepalived 本身无内置仲裁机制 - 物理网络隔离时，两节点都自认为是 master，VIP 会同时存在 —— 此时 MySQL 写冲突无法避免；真正要防的是「写入双主」，不是「VIP 双占」；所以 VIP 高可用必须搭配 MySQL 单写模式（如 MHA 或 Orchestrator 控制写入路由）
- 上线前务必做断网测试：拔掉主节点网线 >10s，观察 VIP 是否迁移、MySQL 是否可连、从库 IO/SQL 线程状态是否正常；别只看 Keepalived 日志
