必须用vrrp_script + weight + fall组合：定义脚本返回非0触发失败计数，fall 3表示连续3次失败才应用weight（如-30），使实际priority=配置priority+weight，结果截断在1～255区间。
keepalived.conf 里怎么写 vrrp_script 实现连续失败3次降权
要让 Keepalived 在健康检查连续失败 3 次后主动降低 priority，不能只靠 priority 静态值，必须用 vrrp_script + weight + fall 组合。核心逻辑是：脚本每次执行返回非 0 → 触发一次“失败计数”，累计达 fall 3 才真正应用 weight 值（比如 weight -30），从而让实际优先级下降。
示例配置片段：
vrrp_script chk_nginx {
script "/usr/bin/killall -0 nginx 2>/dev/null"
interval 2
fall 3
rise 2
weight -30
}注意点：
-
script必须返回 0 表示成功，非 0（如 1）表示失败；killall -0 nginx是轻量级进程存在性检查，比 curl 更快更稳 -
interval 2表示每 2 秒执行一次，配合fall 3，意味着至少 6 秒无响应才触发降权 -
weight -30是“扣分”，不是设置新 priority；若原priority 100，降权后变成 70 -
rise 2要求连续 2 次成功才恢复权重，防止单次瞬时恢复就抢回 VIP
track_script 怎么绑定到 vrrp_instance 才生效
光定义 vrrp_script 不起作用，必须在 vrrp_instance 块里用 track_script 显式引用，否则 Keepalived 完全忽略该脚本。
正确写法：
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
<pre class="brush:php;toolbar:false;">authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.1.100/24
}
track_script {
chk_nginx # 必须和 vrrp_script 名字完全一致
}}
常见错误：
- 脚本名大小写不一致（如定义为
chk_Nginx，但track_script写成chk_nginx）→ 日志报Unknown script 'chk_nginx' - 漏掉
track_script块 → 脚本照常执行，但 weight 永远不叠加，priority 不变 -
state MASTER和priority不匹配（如 priority 80 却设 state MASTER）→ 启动时 warn，可能被强制降为 BACKUP
为什么 fall 3 后 priority 没变？排查关键点
实际运行中常出现“脚本明明失败了，VIP 就是不漂移”，大概率不是配置语法错，而是底层条件没满足导致 weight 未参与计算。
重点检查这几项：
- 确认
virtual_router_id主备节点**完全一致**（比如都是51），差 1 都会导致两节点互不可见，各自当 MASTER - 确认
interface名称主备一致（eth0vsens33是常见坑），否则 VIP 根本绑不上，日志里反复出现invalid interface - 检查防火墙是否放行 VRRP 协议：需允许
proto 112，不是 UDP 端口；CentOS 7+ 默认 firewalld 会拦，用firewall-cmd --add-protocol=vrrp --permanent加规则 - 查看
/var/log/messages或journalctl -u keepalived，搜索Weight decreased by或priority changed，没有这些日志说明 weight 根本没触发 - 用
ip addr show eth0看 VIP 是否已存在；再用killall -0 nginx手动测试脚本返回值，确保它真能失败
weight -30 和 priority 100 一起用，最终优先级怎么算？
Keepalived 的实际运行 priority = 配置的 priority + 所有已触发 weight 值之和，结果会被硬截断在 1～255 区间。
举例说明：
- 初始：
priority 100，脚本未触发 → 实际 priority = 100 - 连续失败 3 次 →
weight -30生效 → 实际 priority = 70 - 此时若 Backup 节点
priority 90，70 - 如果同时配置了另一个脚本
chk_disk，也触发了weight -20，则实际 priority = 100 - 30 - 20 = 50 - 哪怕 weight 算出来是 0 或负得更多，最终不会低于 1；超过 255 也不会高于 255
这个机制意味着：你不需要把 backup 的 priority 设得特别高，只要 master 降权后低于 backup，切换就自然发生——关键是让降权幅度足够大、足够可靠。
