如何设置Redis哨兵模式下的优先级选主_通过slave-priority或replica-priority

replica-priority是Redis从节点在哨兵故障转移时的选举优先级参数，值越小优先级越高，默认100；设为0则永不参选，它仅影响选举权重，不控制数据同步。

Redis哨兵故障转移时，哪个从节点会被选为新主，取决于 replica-priority（5.0+）或 slave-priority（旧版）配置值——值越小，优先级越高；设为 0 则永不参与选举。

replica-priority 是什么，为什么它决定谁当新主

这是 Redis 从节点向哨兵声明“我愿被提拔”意愿的配置项，默认值是 100。哨兵在故障转移阶段筛选候选从节点时，第一轮就按这个值升序排序：比如 replica-priority 10 的节点比 replica-priority 50 的更可能当选。它不控制数据同步行为，只影响选举权重。

注意：slave-priority 是 Redis 5.0 之前的老名字，5.0+ 版本已统一为 replica-priority，但配置文件里写错成 slave-priority 不会报错，只是被忽略——哨兵压根读不到。

• 必须在从节点的 redis.conf 中设置，不是在 sentinel.conf 里
• 修改后需重启 Redis 进程（或用 CONFIG SET replica-priority N 动态生效）
• 设为 0 表示该从节点放弃参选，哪怕它数据最新、运行最稳

怎么配才真正生效：路径、语法、验证三步缺一不可

常见错误是改了配置但哨兵没感知到——往往因为路径不对、格式错、或没验证是否加载成功。

• 配置位置：每个从节点自己的 redis.conf，例如 /etc/redis/6380.conf
• 正确写法：replica-priority 20（前后不能有引号，不能写成 replica-priority="20"）
• 验证是否生效：redis-cli -p 6380 CONFIG GET replica-priority，返回 1) "replica-priority" 2) "20" 才算落地
• 别漏密码：如果主节点有密码，从节点必须配 masterauth <password>，否则复制失败，哨兵会直接过滤掉该从节点

为什么设了 priority 还没当选？排查这三点

即使你把 A 节点设成 replica-priority 10，B 设成 100，A 仍可能落选——因为哨兵选举是多条件流水线筛选，replica-priority 只是第一关。

• 健康检查不过：该从节点必须处于 INFO replication 中 master_link_status:up 状态，且 connected_slaves 显示正常连接
• 复制偏移量落后太多：哨兵会接着比 replica-offset，如果 A 的 offset 比 B 小几百 MB，那 B 会胜出——优先级只在 offset 相近时起作用
• 主观下线未解除：哨兵自己认为该从节点 s_down，哪怕它 ping 得通，也会被跳过；检查 redis-cli -p 26379 SENTINEL slaves mymaster 输出中的 flags 字段是否含 s_down

生产环境典型配置策略

真实部署中不会只靠一个参数拍板，而是组合使用，降低误切风险：

• 机房 A 的从节点（同城）设 replica-priority 10，机房 B（异地）设 90，避免跨机房切主引发高延时
• 某台从节点磁盘 I/O 偏高，临时 CONFIG SET replica-priority 0 让它退出选举池，等负载回落再调回
• 所有从节点都设 replica-priority 100（默认），那就完全依赖 replica-offset 和 run_id 决定，此时数据完整性成为唯一依据

真正容易被忽略的是：哨兵不会告诉你“因为 offset 差太多，所以没选你”，它只安静地执行完三步筛选——所以出问题时，得主动查 INFO replication 和 SENTINEL slaves <master-name>，而不是只盯 replica-priority 配置本身。