哨兵日志看不到选举过程，需先将loglevel设为verbose才能显示+odown、+try-failover等关键事件；默认notice级别会过滤这些信息，导致无法观察选举细节。

哨兵日志里看不到选举过程？先调 loglevel 到 verbose

默认 notice 级别会过滤掉 +odown、+try-failover、+failover-state-select-slave 这类关键事件，等于在黑盒里操作。

• 临时改：用 redis-cli -p 26379 连上任意哨兵，执行 CONFIG SET loglevel verbose
• 永久改：在 sentinel.conf 中加 loglevel verbose，再执行 SENTINEL RELOAD 或重启进程
• 注意：verbose 日志量很大，定位完问题务必调回 notice，否则磁盘和 I/O 压力会突增

看到 +sdown 但没升级成 +odown？检查 quorum 和在线哨兵数是否匹配

+sdown 是单个哨兵的主观判断，真正触发故障转移必须达成 +odown——这需要足够多哨兵共同确认。卡在这一步最常见。

Redis Skill - 高性能缓存管理

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

下载

• 查当前配置：CONFIG GET quorum（注意它绑定在 sentinel monitor 行，不是全局参数）
• 确认实际在线哨兵数：SENTINEL SENTINELS mymaster，返回的数组长度才是真实可用数
• 如果 quorum=2 但只剩 1 个哨兵存活，永远凑不够票数；3 个哨兵建议设 quorum 2，5 个建议设 quorum 3
• 所有哨兵必须能双向通信：检查 sentinel announce-ip 和 sentinel announce-port 是否填了真实可达地址（别写 127.0.0.1），并确认防火墙放行了 26379 端口的 TCP 双向连接

切换成功但客户端连不上新主？重点查 SENTINEL RESET 和 DNS 缓存

哨兵可能还记着旧 master 地址，尤其在原 master 恢复或手动 failover 后未清理状态时。

• 强制刷新：SENTINEL RESET mymaster（mymaster 替换为你监控名），它会清空该 master 的全部缓存状态并重新发现
• 验证结果：SENTINEL MASTER mymaster 查看 ip 和 port 字段是否已更新为当前主节点的真实地址
• 若用 DNS 名（如 redis-prod.example.com）做 master 地址，确保 DNS TTL 足够短（建议 ≤60s），否则哨兵只在初始化或 RESET 时解析一次，不会主动重查

频繁切换根本不在哨兵配置上？先验时钟同步和网络双向连通性

很多人一上来就调 down-after-milliseconds 或 quorum，结果只是掩盖问题。真正根因常是时钟偏差或网络单向隔离。

• 查时钟：每台哨兵和 Redis 节点都运行 ntpstat，输出需为 synchronised to NTP server 且 offset 在 ±50ms 内；更细粒度用 chronyc tracking，System time offset 超 ±100ms 就要干预
• 抓包验证通信：tcpdump -i any port 26379，重点看有没有大量 [TCP Retransmission] 或单向收包无响应——云环境常见安全组只开了入方向，K8s headless Service 下 Pod IP 跨节点不通也常导致丢包
• 别跳过这两步直接改哨兵参数：时钟不同步或网络隔离不解决，延迟只会越来越高，最终法定票数彻底失效

真实场景里，SENTINEL RESET 和时钟校准往往比调参见效更快；而 DNS 缓存和 announce-ip 配错，是生产环境最常被忽略的两个硬伤。