Keepalived故障切换核心依赖VRRP协议：Master每秒发VRRP心跳，Backup连续3个间隔未收到即判定失效，进入FAULT状态并依据priority竞争成为新Master，绑定VIP、发免费ARP完成接管；超时时间由advert_int与fall参数共同决定。
Keepalived 心跳检测失败触发故障切换，核心依赖 VRRP 协议的机制设计，不是“一两次收不到心跳就切”，而是通过连续失败判定 + 优先级比较 + 状态跃迁完成的。关键在于理解它如何把网络通信异常转化为角色变更。
心跳检测失败后怎么触发切换
- Keepalived 主节点（Master）会周期性地以多播方式发送 VRRP 广告报文（即“心跳”），默认每秒 1 次（
advert_int 1），携带自身优先级、状态等信息 - 备节点（Backup）持续监听该多播报文；一旦在 3 个连续广告间隔内（即默认 3 秒）未收到主节点心跳，就判定 Master 不可达
- 此时 Backup 节点立即进入
FAULT状态，随后根据本地配置的priority值，与其他 Backup 节点竞争（若有多备），最终选出新 Master - 新 Master 启动
VIP绑定、ARP 刷新（arping）、服务接管（如启动 Nginx、MySQL 等），完成故障切换
注意：这个“3 秒”不是固定值，由
advert_int和fail参数共同决定。例如advert_int 2; fall 2表示：心跳间隔 2 秒，连续 2 次收不到即触发切换 → 实际超时为 4 秒。
常见导致心跳失败却未切换的原因
-
防火墙拦截 VRRP 多播报文：VRRP 使用协议号 112（非端口），需放行
proto 112或udp port 0（实际不走 UDP 端口） -
网卡或路由问题：心跳走指定网卡（
interface eth0），但该网卡 down、IP 冲突、或未启用 multicast -
优先级配置错误：两节点
priority相同，且都设为nopreempt，可能长期僵持不切换 -
日志被忽略：
/var/log/messages或journalctl -u keepalived中出现VRRP_Instance(VI_1) Sending/Receiving VRRP packet failed才是真实线索
如何验证心跳是否真正失效
- 在 Backup 节点执行
tcpdump -i eth0 vrrp -nn，观察是否收到主节点 VRRP 报文 - 查看 Keepalived 进程状态：
systemctl status keepalived，确认运行中且无ERROR - 检查
/etc/keepalived/keepalived.conf中vrrp_instance段是否正确指定了interface、virtual_router_id（必须主备一致）、priority（Master > Backup）
切换本身不依赖脚本或外部命令，是 Keepalived 内置 VRRP 状态机自动完成的。只要心跳链路断开满足判定条件，且配置无逻辑冲突，切换就会发生。
