replica-priority仅从节点有效，决定故障转移时参选资格与优先级；必须配置在从节点redis.conf中、用正确语法（如replica-priority 10）、且需CONFIG GET验证生效，设为0则彻底弃权参选。

主库没有优先等级——只有从库有 replica-priority，它决定谁在故障时能当新主。

为什么改 replica-priority 但没生效？

常见错误是把配置写在 sentinel.conf 或主节点的 redis.conf 里，而它必须设在「将要参选」的从节点自己的 redis.conf 中。

• 路径错：比如该改 /etc/redis/6380.conf，却去动了 /etc/redis/6379.conf（主节点）
• 名字错：Redis 5.0+ 必须用 replica-priority 10，写成 slave-priority 10 不报错但被忽略
• 格式错：写成 replica-priority = 10 或 replica-priority "10"，实际只认空格分隔的纯数字
• 没验证：改完没执行 redis-cli -p 6380 CONFIG GET replica-priority 确认返回值是否已更新

怎么让某个从节点大概率当选新主？

设低 replica-priority 是第一步，但不是唯一条件。哨兵选举是三轮筛选：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 第一轮筛健康节点：该从节点 INFO replication 中 master_link_status:up 且 connected_slaves 正常；否则直接出局
• 第二轮比数据新鲜度：用 slave_repl_offset 对比原主的 master_repl_offset，差值越小越靠前
• 第三轮比 ID：若前两轮都相同，选 runid 字典序最小的那个——这个没法配，只能接受随机结果

所以，光设 replica-priority 10 不够，还得确保它网络稳定、复制延迟低、没积压 backlog。

设成 0 是不是就绝对不参选？

是的，replica-priority 0 表示“我主动弃权”，哪怕它数据最新、运行最稳，哨兵也会跳过它。

• 适合用在资源受限、仅作冷备或只读分析的从节点上
• 注意：设为 0 后，该节点仍会正常同步数据，只是不参与选举
• 如果误设为 0，又没其他健康从节点，故障转移会失败——哨兵日志里会出现 no suitable slave to promote

真正起作用的从来不是“哪个主更优先”，而是“哪些从更合格”。replica-priority 只是入场券，后面两轮才是决定性环节，容易被忽略的是复制偏移量和连接状态——它们不靠配置，靠实时运行质量。