replica-priority 为 0 表示从库禁止被选为新主，即使唯一存活也会导致故障转移失败；哨兵依据从库 INFO REPLICATION 中上报的值决策，而非本地配置。
replica-priority 为 0 会导致从库完全不参与故障转移
Redis 哨兵（Sentinel）在主库宕机时，会根据从库的 replica-priority 值选主——值越小优先级越高，但 0 是特例：它代表“禁止被选为新主”。哪怕这是唯一存活的从库，哨兵也会跳过它，直接标记整个集群为 fail 状态，不执行任何故障转移。
常见错误现象：+sdown master mymaster 127.0.0.1 6379 后迟迟没有 +odown 或 +try-failover 日志；哨兵日志里反复出现 Ignoring replica ... with priority 0。
- 检查方式：连接任意从库执行
CONFIG GET replica-priority，或查 Redis 配置文件中是否显式写了replica-priority 0 - 生产环境别依赖默认值（默认是 100），务必显式配置，避免被运维脚本、Ansible 模板或容器启动命令意外覆盖为 0
- Docker/K8s 场景下特别容易踩坑：比如 entrypoint 脚本里写了
redis-server --replica-priority 0用于调试，上线时忘了删
哨兵视角下的 replica-priority 是从库上报的，不是哨兵本地配置
哨兵不会读取自己的配置来判断从库优先级，而是通过向从库发送 INFO REPLICATION 获取其当前生效的 replica-priority 值。这意味着：改了 redis.conf 但没 CONFIG REWRITE 或没重启，哨兵看到的仍是旧值。
- 确认真实值必须连到对应从库执行
INFO REPLICATION，找replica-priority:这一行，不是看哨兵配置或 redis.conf 文件内容 - 动态修改用
CONFIG SET replica-priority 10，立即生效且持久化到redis.conf（如果开启了CONFIG REWRITE） - 注意权限：部分云托管 Redis（如阿里云、腾讯云）禁用
CONFIG命令，只能通过控制台或工单修改，这类环境更要提前验证是否支持调优
多个从库 replica-priority 相同时，哨兵按 runid 字典序选主
当几台从库 replica-priority 都设为相同非零值（比如都设成 10），哨兵不会随机选，而是比较它们的 run_id 字符串，选字典序最小的那个。这个行为不可控，也难预测。
- 建议给关键从库设置差异化的
replica-priority（如 10 / 20 / 30），避免靠 runid “碰运气” - 不要把 priority 设得过于接近（比如 99 / 100），因为某些旧版哨兵在浮点计算中可能有精度误差，导致排序异常
- 如果用 Redis 7+ 的
replica-announced模式，还需确认从库是否正确上报了 IP 和端口，否则哨兵可能根本发现不了该节点，更谈不上比 priority
replica-priority 不影响数据同步，只影响哨兵决策
这个配置对复制链路本身毫无影响：从库照样能接收 RDB、AOF、持续增量同步，INFO REPLICATION 里的 master_link_status:up 也不受影响。它纯粹是哨兵做 failover 时的一张“投票表”。
- 所以即使你发现从库同步延迟高、内存占用大，也不要下意识去调
replica-priority——那是治标不治本，该优化网络、带宽或主库写入节奏 - 测试时最容易忽略的一点：哨兵需要多数派（quorum）确认主库客观下线，光改一个从库的 priority 没用；必须确保至少
quorum个哨兵实例都观测到了该从库的有效 priority 值（即从库已重连哨兵并完成 INFO 上报） - 滚动更新从库配置后，记得观察哨兵日志里的
+selected-slave是否出现在预期节点上，而不是只看CONFIG GET返回值
真正卡住晋升的，往往不是 priority 数值本身，而是哨兵压根没拿到它——比如从库刚启动还没来得及上报 INFO，或者哨兵与该从库之间的 TCP 连接被防火墙临时中断过。这种隐性失联比配错数字更难排查。
