keepalived主从角色由priority值刚性裁定，数值大者必为master，需与state、virtual_router_id、authentication协同生效；priority相同或关键参数不一致将导致脑裂或vip漂移异常。

Keepalived 通过 priority 参数直接决定 VRRP 实例在主从切换中的角色归属，不是“自动选举”，而是由数值大小强制裁定。只要配置无误、网络通、认证一致，优先级高的节点必定成为 MASTER，低的为 BACKUP —— 这是实现精准控制的核心逻辑。

priority 是主从判定的刚性依据

Keepalived 不依赖健康检查结果或服务状态来选主，只比对同一 virtual_router_id 下各节点的 priority 值：

• 值越大，越优先抢占 MASTER 角色
• MASTER 节点 priority 必须严格高于所有同 virtual_router_id 的 BACKUP 节点
• 若两节点 priority 相同，且 state 都设为 MASTER，会触发脑裂（VIP 同时出现在两端）
• 实际生产中建议主节点设为 100～150，备节点设为 90～99，留出 10+ 的安全差值

关键配置项必须协同生效

priority 单独设置无效，需与以下三项严格匹配：

• state：主节点写 state MASTER，备节点写 state BACKUP —— 这是角色声明，但最终以 priority 裁决
• virtual_router_id：主备必须完全一致（1–255 范围内），否则不视为同一组 VRRP 实例，互不感知
• authentication：auth_type 和 auth_pass 必须完全相同，否则心跳包被拒绝，无法同步状态

避免常见误配导致失效

以下错误会让 priority 失去作用，甚至引发 VIP 漂移异常：

• 主备节点 interface 名称不一致（如一端写 ens33，另一端写 eth0），VIP 无法绑定到正确网卡
• router_id 相同（如都写成 LVS_DEVEL）—— 虽不直接干扰 priority，但会导致日志混乱、故障排查困难
• vrrp_strict 开启时，要求 global_defs 中的配置更完整（如 smtp_server），否则服务启动失败，VIP 根本不生效
• 防火墙拦截了 VRRP 组播包（默认目的地址 224.1.1.1，协议号 112），导致心跳中断，BACKUP 误判为主节点宕机而抢 VIP

验证 priority 是否生效的实操方法

不要只看配置文件，要观察运行时行为：

• 启动后执行 ip -br a show，确认 VIP 只出现在 priority 更高的一端
• 在两端分别执行 tail -f /var/log/messages | grep "VRRP"，观察日志中是否出现 “Becoming MASTER” 或 “Entering BACKUP STATE”
• 手动停止高 priority 节点的 keepalived：systemctl stop keepalived，1 秒内 VIP 应漂移到低 priority 节点；恢复后，VIP 应立即切回（因 preemption 默认开启）
• 用 tcpdump -i ens33 vrrp 抓包，确认 MASTER 发送 advertise，BACKUP 仅监听不响应