哨兵日志看不到选举过程，需先将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 配错，是生产环境最常被忽略的两个硬伤。 
