Keepalived中priority是主从角色的刚性裁定依据：数值越大越确定成为MASTER，同一virtual_router_id下谁当MASTER完全由priority大小决定；必须配合state、virtual_router_id和authentication严格一致才能生效。
Keepalived 中定义故障转移优先级，核心就是配置 priority 参数。它不是辅助参考值，而是主从角色的刚性裁定依据：数值越大，越确定成为 MASTER；数值小的自动进入 BACKUP 状态。
priority 是主从切换的决定性参数
同一 virtual_router_id 下的节点，谁当 MASTER 完全由 priority 数值大小决定：
- MASTER 节点必须设为明确高于所有 BACKUP 节点的值（例如 120 vs 90）
- 若两节点 priority 相同，且 state 都配成 MASTER，会同时绑定 VIP，引发脑裂
- 生产环境建议留出 ≥10 的差值（如主 110，备 95），避免因配置微小偏差导致异常
priority 必须配合关键配置项生效
单独改 priority 没用，以下三项必须严格一致或匹配：
-
state：主节点写
state MASTER，备节点写state BACKUP（这是角色声明，但最终以 priority 裁决） - virtual_router_id：主备必须完全相同（取值 1–255），否则不视为同一组 VRRP 实例
- authentication：auth_type 和 auth_pass 必须完全一致，否则心跳包被丢弃，BACKUP 无法感知 MASTER 状态
让 priority 在真实故障中可靠起作用
常见配置错误会让 priority 失效，甚至导致 VIP 漂移混乱：
- 主备节点
interface名称不一致（如一端写 eth0，另一端写 ens33），VIP 无法正确绑定网卡 - 防火墙未放行 VRRP 组播（目的地址 224.0.0.18，协议号 112），心跳中断，BACKUP 误判为主宕机而抢 VIP
- 开启
vrrp_strict时，global_defs 中缺少必要字段（如 smtp_server），会导致 keepalived 启动失败
验证 priority 是否按预期工作
不要只看配置文件，要观察运行时行为：
- 启动后执行
ip -br a show，确认 VIP 只出现在 priority 更高的一端 - 在两端分别执行
tail -f /var/log/messages | grep "VRRP"，观察是否出现 “Becoming MASTER” 或 “Entering BACKUP STATE” - 手动停止高 priority 节点：
systemctl stop keepalived，1 秒内 VIP 应漂移到低 priority 节点；恢复后应立即切回（preemption 默认开启）
