redis哨兵主从切换失败绝大多数情况是选主后卡在promotion或slaveof-noone阶段超时，典型日志信号为-failover-abort-slave-timeout或-failover-abort-no-good-slave，需优先排查config禁用、密码不匹配、端口不通、客户端连接池未刷新四类问题。
Redis哨兵主从切换失败，**绝大多数情况不是哨兵没选主，而是选完后卡在 promotion 或 slaveof-noone 阶段超时**。日志里出现 -failover-abort-slave-timeout 或 -failover-abort-no-good-slave 就是典型信号，得立刻查 CONFIG、密码、端口、连接池四类问题。
看到 -failover-abort-slave-timeout，先检查 rename-command CONFIG
哨兵在 promote 从节点前，必须执行 CONFIG REWRITE 和 CONFIG SET 来持久化新角色（如把 slaveof 清空、写入 masterauth 等）。如果 Redis 配置中禁用了 CONFIG：rename-command CONFIG ""，哨兵就会一直等不到响应，最终超时放弃。
- 确认方式：登录任意 Redis 实例，执行
CONFIG GET CONFIG—— 如果返回错误或空，说明被重命名/禁用 - 临时验证：在 redis.conf 中注释掉
rename-command CONFIG行，redis-cli CONFIG REWRITE后重启实例 - 注意：不能只改哨兵配置，必须改所有 Redis 实例（主 + 从）的
redis.conf，否则切换后旧 master 恢复时仍会出问题
哨兵日志显示 +elected-leader 但卡在 +failover-state-wait-promotion
这说明哨兵已选出 leader 并选定从节点，但在等待该从节点真正完成角色升级（即执行 SLAVEOF NO ONE 并确认状态为 role:master）。常见阻塞点：
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 目标从节点的
protected-mode yes且bind未放开：哨兵发命令过去被拒绝，需设bind 0.0.0.0+protected-mode no - 从节点设置了
requirepass但没配masterauth：哨兵要用密码连它执行命令，没masterauth就认证失败 - 防火墙拦了从节点的 Redis 端口（如 6379）：哨兵和从节点之间 TCP 连不通，telnet 测试最直接
- 从节点本身负载高或内存满，
SLAVEOF NO ONE执行缓慢甚至 hang 住
Spring Boot 应用不感知切换，连接仍打向旧 master
这不是哨兵的问题，是客户端连接池没刷新地址。Lettuce 默认启用连接池缓存，且对哨兵事件响应不敏感，尤其在短超时（如 timeout=600）下容易卡死旧连接。
- 现象：哨兵日志已显示新 master 上线，但应用
redisTemplate.opsForValue().get()报Connection refused或超时 - 验证方式：用
redis-cli -h 新master-ip -p 6379 PING确认新 master 可达 - 修复路径：升级到 Lettuce 6.1+ 并启用
discoveryClients，或更稳妥地切换为 Jedis（需排除lettuce依赖） - 关键参数：无论用哪个客户端，
sentinel.master名必须和哨兵配置中sentinel monitor <master-name></master-name>完全一致，大小写敏感
哨兵自己无法达成 quorum，始终不触发 failover
哨兵不是“一票否决”，而是需要多数派同意才能推进。日志里长期停在 +sdown / +odown 却无 +try-failover，大概率是投票数不足。
- 检查
quorum值：在sentinel.conf中sentinel monitor mymaster 127.0.0.1 6379 2的最后一个数字，必须 ≤ 在线哨兵数且 ≥ ⌊N/2⌋+1（N 为总哨兵数） - 常见坑：三哨兵却设
quorum 3→ 永远投不出结果；单机部署多哨兵但没开port或防火墙拦截哨兵间通信（26379 端口互 ping） - 强制触发测试：用
redis-cli -p 26379 sentinel failover mymaster手动触发，看是否报NOGOODSLAVE或NOQUORUM
真正难定位的往往是组合问题：比如 CONFIG 被禁用 + 从节点 masterauth 缺失 + Lettuce 连接池未刷新，日志里只显示一个超时，但根因分散在服务端、中间件、客户端三层。每次只改一个点，再观察日志变化，比堆参数更有效。
