Keepalived备份节点故障转移测试关键在于模拟主节点失效并验证VIP漂移和服务连续性：先确认主节点持有VIP且处于MASTER状态、备节点为BACKUP；再通过停止Keepalived服务等方式触发失效；随后观察备节点是否成功绑定VIP、进入MASTER状态并响应服务请求。
测试 Keepalived 备份节点的故障转移，关键在于模拟主节点失效，并验证 VIP 是否按预期漂移到备节点、服务是否持续可用。整个过程不需要修改配置，只需触发状态变化并观察日志与网络行为。
确认主备状态和 VIP 初始归属
先在两台节点上分别执行：
-
查看 Keepalived 当前角色：运行
ip addr show或systemctl status keepalived，确认 VIP（如 192.168.1.100）只绑定在主节点网卡上，备节点无该 IP -
检查 VRRP 状态：执行
journalctl -u keepalived -n 50 --no-pager，主节点应有Entering MASTER STATE，备节点为Entering BACKUP STATE - 验证服务可达性：用客户端（如 curl、mysql 客户端或 telnet）通过 VIP 访问服务，确保正常响应
主动触发主节点失效
有三种常用方式，按可控性和贴近真实场景推荐顺序排列：
-
停掉 Keepalived 服务（最直接）：
sudo systemctl stop keepalived。这是最干净的模拟，避免干扰 MySQL/Nginx 等被监控服务 -
杀掉 Keepalived 进程：
sudo pkill keepalived。适用于服务未被 systemd 正确管理的旧环境 -
让健康检查失败（更贴近生产）：比如停掉被
track_script监控的 MySQL 或 Nginx，例如sudo systemctl stop mysqld。Keepalived 检测到脚本返回非零值后会自动降级
观察备节点接管行为
主节点操作后，立即在备节点上检查：
-
VIP 是否已绑定：运行
ip addr show，确认虚拟 IP 已出现在本地网卡（如 eth0）下 -
Keepalived 日志是否有 MASTER 切换记录：执行
journalctl -u keepalived -n 30 --no-pager | grep -i "master\|transition"，应看到类似VRI: Entering MASTER STATE的日志 -
是否发出免费 ARP：可选，用
tcpdump -i eth0 arp抓包，能看到备节点广播 ARP 告知局域网“VIP 新的 MAC 地址在此” -
服务是否响应正常：从外部机器用 VIP 访问服务（如
mysql -h 192.168.1.100 -u root -p），确认连接成功且数据一致
恢复主节点并验证是否回切（可选）
若配置了 preempt（默认开启），主节点恢复 Keepalived 后会重新抢回 VIP；若配置了 nopreempt，则不会回切，需手动干预。测试时建议：
- 启动主节点 Keepalived：
sudo systemctl start keepalived - 等待 1–3 秒，检查主节点日志是否出现
Entering MASTER STATE - 再次运行
ip addr show，确认 VIP 已回到主节点 - 注意：若使用
nopreempt，备节点将长期持有 VIP，这是设计行为，不是故障
