slave-priority 0 不等于禁止晋升，仅表示“尽量不选”；当所有从库均为0时，哨兵仍会选复制最完整者提拔为新主库，因故障转移必须选出主库。
不能靠 slave-priority 0 完全阻止从库被选为新主库，它只影响“优先级排序”，不等于“禁止晋升”。
为什么 slave-priority 0 不等于“永不提拔”
Redis 哨兵在故障转移时，会先过滤掉主观下线、连通性差、复制偏移量严重滞后的从库，再按 slave-priority 排序。但若所有从库都设置了 slave-priority 0，哨兵仍会从中挑一个（比如复制最完整、响应最快的）强行提升——因为必须选出一个新主库，否则集群不可写。
-
slave-priority 0的真实含义是“请尽量别选我”，不是“禁止选我” - 哨兵不会跳过所有
slave-priority 0的节点去等一个不存在的“非零节点” - 如果主库宕机且只剩一个从库（哪怕
slave-priority 0），它一定会被提拔
真正能阻止自动提升的配置组合
想让某台从库彻底不参与选举，光设 slave-priority 0 不够，得配合其他机制切断“可选性”：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在该从库的
redis.conf中设置replica-read-only yes（默认值，确保它不接受写） - 在对应哨兵配置中，给该实例显式添加
sentinel replica-ignore-maxmemory no（不相关，忽略）→ 实际应做的是：在哨兵配置里用sentinel down-after-milliseconds <name> 5000</name>缩短检测窗口？不对——重点是：不加任何sentinel monitor监控它，即：哨兵进程根本不知道这台机器是某个主库的从库 - 更可行的做法：在该从库上执行
CONFIG SET replicaof no one，让它脱离复制关系；此时它变成独立节点，哨兵自然不会把它纳入故障转移候选池 - 若需保留复制链但禁止晋升，唯一稳妥方式是：让该从库始终与主库断开复制（如防火墙拦截
REPLCONF心跳），使哨兵判定它“主观下线”，从而跳过
slave-priority 0 的典型误用场景
常见于想搭建“冷备从库”或“分析专用从库”，结果发现主库一挂，这个库还是被提成了主库，业务流量打进来直接报错。
- 误以为设了
slave-priority 0就高枕无忧，没检查哨兵日志里是否仍有+selected-slave记录指向它 - 忘记该从库的
INFO replication输出中master_link_status:up仍为 up，说明它还在正常同步，哨兵就认为它是健康候选者 - 在多哨兵部署中，只改了部分哨兵的配置，导致某些哨兵仍把它当有效从库看待
- 使用 Redis 6.2+ 时，
slave-priority已更名为replica-priority，旧配置项会被忽略但无警告
真正要“防提拔”，核心不是调参数，而是控制哨兵对这个实例的感知状态——让它要么不在监控列表里，要么持续处于不可达/断连状态。参数只是辅助排序，不是开关。
