哨兵leader选举失败根本原因是法定票数未达成或投票未启动：quorum值与在线且互通的哨兵数不匹配（如设2但仅1台可达）、sentinel monitor配置未同步、网络不通（26379/6379端口阻塞）、ntp偏移超5秒或config命令被rename导致故障转移中断。
哨兵Leader选举失败，基本就是法定票数没凑够，或者根本没进入投票环节。 它不是“投不出结果”，而是压根没启动有效投票——多数情况连客观下线（+odown）都没达成，更别说选Leader了。
quorum值和在线哨兵数对不上
quorum不是摆设，它直接决定能否触发客观下线和后续投票。设成2，但实际只有1个哨兵能和其他节点通信（比如防火墙拦了26379端口），SENTINEL ckquorum mymaster会直接报missing+quorum，整个流程卡死。
- quorum应设为
floor(N/2)+1，3个哨兵就设2，5个就设3；设成偶数（如2配3节点）反而容易分裂投票 - 别只改配置文件——必须在每台哨兵上执行
SENTINEL monitor mymaster 127.0.0.1 6379 2强制刷新，否则重启前仍是旧视图 - 用
SENTINEL masters和SENTINEL sentinels mymaster逐台比对输出，不一致说明sentinel monitor没同步全
哨兵之间或与Redis节点网络不通
哨兵靠PING/PONG和hello消息维系集群视图。26379端口不通，或哨兵连不上主从的6379端口，会导致部分哨兵“失联”，形成孤立子集群。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
telnet <sentinel-ip> 26379</sentinel-ip>和redis-cli -h <redis-ip> -p 6379 PING</redis-ip>双向验证连通性 - 检查防火墙是否放行
26379（哨兵间）和6379（哨兵→Redis）端口 - NTP时间偏移超过5秒，可能让
down-after-milliseconds判定失效，间接导致主观下线不统一
CONFIG命令被rename导致failover中断
Leader执行故障转移时，需要调用CONFIG命令获取从库配置、设置slaveof no one等。如果配置了rename-command CONFIG "CHAOSCONFIG"，Leader会因权限拒绝或命令不存在而失败，日志里出现failover-abort-slave-timeout或failover-abort-no-good-slave。
- 确认
redis.conf中没有重命名CONFIG、SLAVEOF、INFO等关键命令 - 即使其他命令重命名了，也务必保留
CONFIG原名，或在哨兵配置中显式指定sentinel config-epoch（不推荐，兼容性差） - 该问题在Redis 4.x常见，升级到6.2+后部分缓解，但rename仍需谨慎
真正卡住的地方往往不是算法本身，而是quorum没生效、网络断点藏得深、或者一个被rename的CONFIG命令让Leader在最后一步跪倒。盯住SENTINEL ckquorum输出和+odown日志，比盯着选举逻辑本身更管用。
