当 SENTINEL ckquorum 返回 ERR 时，这通常是排查 Redis 哨兵模式主节点选举超时最直接、最明确的信号，说明当前可互相通信的哨兵数量不足 quorum 要求，因此系统无法进入客观下线（odown）与自动故障转移流程；此时应立即检查 SENTINEL sentinels mymaster 的返回数量、哨兵之间的网络连通性，以及 quorum 动态配置是否真正生效。

SENTINEL ckquorum 返回 ERR 是最直接信号

如果你在日志中持续看到missing+quorum或failover-abort-no-good-sla ve，先不要急着只检查从库，优先执行SENTINEL ckquorum mymaster。该命令不会模拟整个选举过程，它只验证一件关键事情：当前存活且彼此可通信的哨兵数量，是否已经达到或超过配置的quorum值。

常见报错表现包括：

• SENTINEL ckquorum mymaster 返回 ERR，并提示 Quorum not reached，这表示投票数根本不足，后续客观下线和故障转移流程都不会启动
• 哨兵进程明明有 3 个，但 SENTINEL sentinels mymaster 只返回 1 条或 2 条记录——通常说明部分哨兵出现网络隔离，例如防火墙未放通 26379 端口的双向通信
• quorum 配置为 3，但实际在线哨兵只有 2 个；或者虽然部署了 4 个哨兵，却设置了 quorum 3，其中一台又因 NTP 时间偏差过大而被其他哨兵拒绝握手

修复时应逐台执行 SENTINEL set mymaster quorum 完成动态调整，仅修改配置文件后再执行 SENTINEL RELOAD 并不能达到预期效果。Redis 3.2+ 支持该命令，执行完成后，可立即通过 SENTINEL master mymaster 输出中的 quorum 字段确认是否已更新。

sla ve 的 master_link_status:down 比你想象中更常见

failover-abort-no-good-sla ve 这类日志并不只是表示“选不出合适的 sla ve”，更准确地说，是哨兵遍历完所有已知从节点后，没有任何一个通过最基本的健康检查——如果复制链路本身已经中断，这些从节点自然不可能参与后续晋升判断。

不要只依赖 SENTINEL masters 输出中的 num-sla ves，而应该逐台登录每个从节点，执行：

redis-cli -p 6379 INFO replication

排查时重点关注以下三项：

• role:sla ve —— 必须显示为 sla ve，不能是 master 或 unknown
• master_host 和 master_port —— 必须仍然指向当前故障主节点，不能出现 nohost 或 0
• master_link_status:up —— 这是关键指标！如果状态为 down，再继续查看 master_last_io_seconds_ago 是否大于 down-after-milliseconds（默认 30000），一旦超时就会被哨兵判定为不可用

常见原因包括：

• 从节点启用了 requirepass，但哨兵未配置 sentinel auth-pass，认证失败后会直接被记录为离线
• 从节点绑定了 bind 127.0.0.1，导致其他机器上的哨兵无法建立 TCP 连接
• 防火墙或云安全组没有放行从节点 Redis 端口（如 6379），使哨兵无法正常探测

日志级别设为 verbose 才能看到真实选举卡点

默认的 loglevel notice 会过滤掉 +odown、+try-failover、+failover-state-select-sla ve 等关键事件。如果不提升日志级别，排查 Redis 哨兵选举超时问题时往往像“蒙着眼睛找故障”。

临时开启（重启后失效）：

CONFIG SET loglevel verbose

如需永久生效，可在 sentinel.conf 中加入 loglevel verbose，然后执行 SENTINEL RELOAD 或直接重启进程。需要注意，生产环境排查结束后应及时恢复为 notice，避免日志量过大。

重点留意以下日志线索：

• 只有 +sdown 而没有 +odown → 通常意味着 quorum 未达标，或哨兵之间通信异常
• 反复出现 Failed to resolve master address → 说明哨兵可能缓存了旧的 master 地址，可执行 SENTINEL RESET mymaster 清理状态
• 日志中的 announce-ip 显示为 127.0.0.1 或其他内网不可达地址 → 在容器或 K8s 环境中，必须显式配置一个可被其他哨兵访问的真实 IP

选举慢往往卡在从节点筛选阶段而非投票本身

Redis Sentinel 的主节点切换通常分为两步：第一步是选出 leader 哨兵（类似 Raft 的投票机制），第二步是由 leader 从可用从节点中挑选新主。实际排查中，耗时更长的往往不是前者，而是后者，尤其是在多个从节点延迟接近、优先级一致、复制偏移量差异极小时更明显。

leader 的筛选逻辑会严格按以下顺序进行：

• 先排除 replica-priority 0 的节点
• 再排除 master_link_status:down 的节点
• 然后选择 replica-priority 最高的节点 → 如果优先级相同，则比较 offset 最大者 → 若 offset 仍相同，再比较 run_id，取字典序最小者

几个经常被忽略、但会直接影响主节点选举速度的细节：

• down-after-milliseconds 在哨兵和从节点上的配置应保持一致，否则从节点可能比哨兵更早判定主库断连，导致 master_link_status 提前变成 down
• 从节点若配置了 replica-serve-stale-data no，并且在主从断开后拒绝对外响应，哨兵就有可能将其误判为不可用节点
• 如果 master 地址使用的是 DNS 名称，TTL 过长会导致哨兵长时间缓存失效解析结果，建议优先使用固定 IP，或采用较短 TTL 的 DNS 配置