Redis哨兵监控异常_检查sentinel log查看详细的选举与切换报错信息-Redis-PHP中文网

需将sentinel日志级别设为verbose才能看到选举过程，因默认notice级别会过滤+odown、+try-failover等关键事件；检查quorum配置与在线sentinel数量是否匹配，确保客观下线能触发；确认announce-ip/port配置正确且网络互通；执行sentinel reset可强制刷新master地址。

redis哨兵监控异常_检查sentinel log查看详细的选举与切换报错信息

sentinel日志里看不到选举过程？先确认日志级别是否为verbose

Redis Sentinel默认日志级别是notice，这个级别会过滤掉选举细节（比如+odown、+try-failover、+failover-state-select-slave等关键事件）。不改日志级别，等于盲操作。

检查当前配置：CONFIG GET loglevel（在sentinel节点上用redis-cli -p 26379连）
临时提升：执行CONFIG SET loglevel verbose（重启后失效）
永久生效：在sentinel.conf中添加或修改loglevel verbose，然后SENTINEL RELOAD或重启进程
注意：verbose会产生大量日志，生产环境建议只在排查期开启，问题定位后调回notice

看到`+sdown`但没触发`+odown`？检查quorum和sentinel数量是否达标

+sdown只是单个sentinel主观下线，真正触发故障转移必须达成客观下线+odown——这需要足够多的sentinel节点共同认定。常见卡点在这里。

Redis Skill - 高性能缓存管理

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

下载

quorum值必须≤实际在线的sentinel总数，否则永远凑不够投票数；例如sentinel monitor mymaster 127.0.0.1 6379 2设了quorum=2，但只剩1个sentinel活着，就无法升级为+odown
所有sentinel必须能互相通信：检查sentinel announce-ip和sentinel announce-port是否填了容器/云环境里实际可被其他sentinel访问的地址（不是127.0.0.1或内网不可达IP）
防火墙或安全组要放行sentinel端口（默认26379）之间的TCP双向连接，不只是client端口

日志里反复出现`Failed to resolve master address`？master地址被sentinel记死了

当原master宕机后恢复，又或者做了手动failover但没清理旧状态，sentinel可能还缓存着已失效的master地址，导致新选举时尝试连接一个根本不存在的IP:port。

强制刷新：在任意sentinel节点执行SENTINEL RESET mymaster（mymaster替换成你的monitor name），它会清空对该master的所有状态并重新发现
确认重发现结果：SENTINEL MASTER mymaster查看ip和port字段是否已是当前主节点的真实地址
如果用DNS名做master地址（如redis-prod.example.com），确保DNS解析稳定且TTL够短，否则sentinel不会主动重查——它只在初始化或RESET后解析一次

切换成功但客户端连不上新master？检查sentinel是否正确通告了新地址

客户端靠sentinel获取master地址，而sentinel靠announce-ip/port告诉客户端“该连谁”。若这两项配置错误，客户端拿到的就是错的地址，哪怕选举本身完全成功。

运行SENTINEL SENTINELS mymaster，看返回列表中每个sentinel的ip和port字段——它们必须是客户端网络可达的地址，不能是docker bridge IP或k8s ClusterIP
如果部署在Docker或Kubernetes里，务必显式设置sentinel announce-ip 10.10.20.5（宿主机IP）和sentinel announce-port 26379，否则默认广播的是容器内部地址
客户端SDK（如Jedis、Lettuce）通常只从第一个响应的sentinel拉取master信息，所以要确保至少一个sentinel的announce配置正确，而不是依赖“多数”