Redis哨兵故障转移阻塞问题排查

Redis哨兵故障转移阻塞的核心问题往往并非Redis实例本身宕机，而是哨兵集群无法就主节点“客观下线”达成quorum共识，导致选举卡死、写请求超时、客户端连接中断；根本原因集中在quorum配置不当、哨兵间26379端口网络不通（单向连通、防火墙拦截、安全组限制）、monitor配置不一致（IP/域名混用、端口错误）以及容器或云环境下的网络地址暴露异常（如Docker内网IP未正确宣告）；快速定位需结合sentinel masters与sentinel sentinels命令验证集群连通性与状态同步，并双向telnet测试，而非盲目调整超时参数。

哨兵判定主节点“客观下线”失败的常见现象

客户端连接突然断开、写请求超时，但 redis-cli -p 26379 info sentinel 显示主节点仍被标记为 master-status:ok，或 sentinels 数量少于预期 —— 这往往不是 Redis 实例挂了，而是哨兵之间没达成共识。

根本原因在于：单个哨兵触发 SDOWN（主观下线）很容易，但必须有 ≥ quorum 个哨兵也报告该主节点失联，才能升级为 ODOWN（客观下线）并启动选举。若哨兵间通信延迟高、丢包或配置不一致，就卡在“多数派无法确认”这一步。

• quorum 值设得过大（比如 3 个哨兵却配成 quorum 3），实际只要 1 个哨兵网络抖动，就永远凑不够票数
• 哨兵之间未互通 port（默认 26379）或防火墙拦截了 TCP 连接，sentinel known-sentinel 查不到其他哨兵
• 各哨兵配置的 sentinel monitor 中主节点地址不统一（如混用 IP 和域名、或端口写错），导致它们监控的是“逻辑上不同的主节点”

检查哨兵集群连通性与状态同步

先确认哨兵是否真的组成了集群，而不是各自为战：

在任一哨兵节点执行：

redis-cli -p 26379 sentinel masters

看返回的 num-sentinels 是否等于你部署的哨兵总数；再执行：

redis-cli -p 26379 sentinel sentinels mymaster

（mymaster 替换为你配置的 master-name）检查每个已知哨兵的 flags 字段 —— 正常应含 disconnected 以外的状态，且 last-ping-sent 和 last-ok-ping-reply 时间差不应超过 1 秒。

• 若 last-ping-sent 很大但 last-ok-ping-reply 为空，说明该哨兵收不到其他哨兵的响应，优先查本机 telnet 26379
• 若 flags 含 odown 但 num-sentinels 明显偏少，可能是部分哨兵启动时没加载正确配置，或 --sentinel 参数漏加
• 注意：哨兵之间使用 TCP 长连接，不依赖 Redis 主从复制通道，别误用 redis-cli -p 6379 测试

故障转移卡在“选举领导者”阶段的典型日志线索

当主节点宕机后，哨兵日志中反复出现类似以下内容，就是选举受阻：

+sdown master mymaster 192.168.2.20 6379<br><code>+odown master mymaster 192.168.2.20 6379 #quorum 2/3</code><br><code>+try-failover master mymaster 192.168.2.20 6379</code><br><code>+vote-for-leader xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 2</code><br><code>+failover-abort-no-good-slave master mymaster 192.168.2.20 6379</code>

关键点在 #quorum 2/3 —— 表示当前只有 2 票认可 ODOWN，但需要 3 票才够；而最后一行 +failover-abort-no-good-slave 实际是误导，真正拦住选举的是前面那句“票数不足”。

• 不要急着调 sentinel failover-timeout，它只控制单次选举耗时上限，解决不了投票失败根源
• 检查所有哨兵的 sentinel monitor mymaster ... quorum 配置是否完全一致（尤其注意空格和大小写）
• 如果哨兵跨公网或高延迟网络部署，把 sentinel down-after-milliseconds 调大（如从 5000 改为 15000），避免因瞬时抖动触发误判

真实环境中最容易被忽略的网络配置点

很多团队在容器或云主机上部署哨兵后故障转移变慢甚至失败，问题不在 Redis 本身，而在底层网络假设被打破：

• 哨兵默认通过 INFO replication 获取从节点 IP，若从节点运行在 Docker 内且未配置 bind 或 announce-ip，哨兵拿到的是容器内网 IP（如 172.17.0.3），其他哨兵根本连不上
• 云厂商安全组常默认放行入方向，但限制出方向 —— 哨兵 A 能连哨兵 B，B 却连不回 A，导致心跳单向成功，状态不同步
• Kubernetes 中若哨兵用 HostNetwork 模式，需确保 hostPort 与配置文件中监听端口严格一致，否则 sentinel known-sentinel 显示的地址是错的

验证方式很简单：在哨兵 A 上执行 telnet <哨兵B的announce-ip> ，再反向执行一次 —— 必须双向通。

好了，本文到此结束，带大家了解了《Redis哨兵故障转移阻塞问题排查》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多数据库知识！