SENTINEL masters显示slave全odown或空列表，说明哨兵已判定主节点客观下线但无法发现可用从节点，根本原因是网络层阻断（如防火墙、bind配置错误、auth-pass未配）或从节点自身复制链路中断（master_link_status: down），导致哨兵既连不上slave，也无法通过INFO replication确认其健康状态。
SENTINEL masters 显示所有 slave 状态为 odown 或空列表
这说明哨兵已判定主节点客观下线，但找不到可用从节点参与选举——不是“挑不出好 slave”，而是“根本看不见活着的 slave”。常见现象是 SENTINEL masters 输出中 num-slaves 为 0，或每个 slave 的 flags 字段含 odown 而非 online。
根本原因通常是网络层阻断：哨兵能连上 master（所以能判定 odown），但无法与任何 slave 建立 TCP 连接。典型诱因包括：
- slave 所在机器防火墙未开放 Redis 服务端口（如
6379）或哨兵通信端口（26379） - slave 配置了
bind但未绑定监听地址（如只绑127.0.0.1），导致哨兵从其他机器 ping 不通 - slave 启用了
requirepass但哨兵没配sentinel auth-pass，连接被拒绝后直接标记为离线 - slave 进程实际已崩溃，但哨兵尚未完成下线判定（此时
INFO replication在 slave 本机返回异常）
检查 slave 是否真的响应 INFO replication
别只信 SENTINEL sentinels mymaster 的输出。逐台登录每个 slave 机器，用 redis-cli -p 6379 INFO replication 直接查它自己的状态。重点看三行：
-
role:slave—— 必须是 slave，不是 master 或 unknown -
master_host:xxx和master_port:xxx—— 必须指向当前故障的 master，且不能是nohost或0 -
master_link_status:up—— 关键！若为down，说明 slave 自己就断开了和 master 的复制链路，哨兵会跳过它
如果 master_link_status 是 down，再查 master_last_io_seconds_ago：值大于 down-after-milliseconds（默认 30000）就会被哨兵认为不可用。
-failover-abort-no-good-slave 日志的真实含义
这个错误不是说“有 slave 但质量差”，而是哨兵遍历完所有已知 slave 后，一个都没通过基础健康检查。触发条件包括：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 所有 slave 的
slave-priority都设为0（显式禁止被提拔） - 所有 slave 的复制偏移量（
offset）都落后 master 太多，超过min-slaves-max-lag阈值 - 所有 slave 的
master_link_down_since_seconds时间戳 >max-master-down-time（哨兵源码里硬编码为master->info_refresh * 2，通常约 2 分钟） - slave 启用了 ACL 但哨兵没配对应用户权限（Redis 6+）
注意：max-master-down-time 不是配置项，是哨兵内部计算值。如果 slave 长时间失联后突然恢复，但哨兵还没来得及刷新它的 info，它仍会被跳过。
为什么改完配置文件不生效？必须用 SENTINEL set
哨兵运行时完全忽略 sentinel.conf 文件里的静态配置。比如你发现 slave-priority 设错了，改完配置文件重启哨兵？不行。因为：
- 哨兵启动后，只读一次配置文件，之后所有状态都存在内存里
-
slave-priority是 slave 自己的配置，必须在 slave 上执行CONFIG SET slave-priority 100 - 哨兵对 slave 的认证凭据（
auth-pass）也必须用SENTINEL set mymaster auth-pass <password></password>动态写入，否则仍按空密码尝试
最容易被忽略的是：改完 slave 的 slave-priority 后，要等哨兵下次执行 INFO replication（默认每 10 秒一次）才能感知到新值。期间日志里仍会报 no-good-slave。
真正卡住选举的，往往不是算法逻辑，而是某个 slave 的 master_link_status 没变 up，或者哨兵压根连不上那个 slave 的 6379 端口——这两点不解决，调再高的 quorum 都没用。
