keepalived 不直接修复故障服务，而是通过健康检查脚本在故障转移前主动抢救、转移中完成 vip 漂移与免费 arp 通知、转移后由备机启动服务并持续监控，实现“自动修复”。
Keepalived 本身不直接“修复”故障服务（比如重启 MySQL 或 Nginx），它的核心职责是检测异常、触发 VIP 漂移、完成角色切换。所谓“自动修复”，实际是通过健康检查脚本 + 状态联动机制，在故障转移前后主动干预底层服务，从而实现“恢复服务”或“加速接管”。这不是 Keepalived 内置功能，而是靠合理配置达成的协同效果。
下面从三个关键环节讲清楚如何落地：
故障转移前：用 check script 主动抢救服务
Keepalived 支持 vrrp_script 自定义检测逻辑。脚本可尝试重启故障进程（如 nginx、mysqld），成功则避免漂移；失败再降权或停服，触发备机接管。
常见做法：
- 检测进程是否存在（
ps -C nginx --no-header） - 发起 HTTP 请求验证服务响应（比进程检测更准确）
- 尝试 systemctl restart，等待几秒后二次校验
- 若仍失败，执行
systemctl stop keepalived或ip addr flush，主动让出 VIP
例如 chk_mysql.sh 中：
if [ $status -eq 0 ]; then
systemctl start mysqld
sleep 2
status=$(ps -C mysqld --no-heading | wc -l)
if [ $status -eq 0 ]; then
systemctl stop keepalived # 主动退出，促发切换
fi
fi
故障转移中：VIP 漂移 + 免费 ARP 通知网络
主节点失联后，备节点按优先级升为 MASTER，立即：
- 绑定虚拟 IP 到本地网卡
- 发送 Gratuitous ARP 报文，刷新交换机/网关的 MAC 表
- 客户端后续请求自然流向新主机，无需改 DNS 或客户端配置
整个过程通常在 3 秒内完成（取决于 advert_int 和 nopreempt 设置）。
故障转移后：备机启动服务并持续监控
备机成为新 MASTER 后，需确保自身服务已就绪：
- 启动依赖服务（如先启 nginx，再启 keepalived）
- 通过
track_script关联健康检查，持续验证服务可用性 - 若新 MASTER 自身服务异常，会再次触发降级，形成闭环保护
注意：若使用非抢占模式（
nopreempt），原 MASTER 恢复后不会抢回 VIP，避免震荡；若需自动回切，可配合权重动态调整（如脚本成功时weight +50）。
本质上，“自动修复” = 主动抢救 + 平滑切换 + 备机自检。Keepalived 提供的是调度框架和决策引擎，真正修复动作由外部脚本完成，灵活且可控。
