哨兵日志反复出现 missing+quorum，说明故障转移因在线哨兵数不足 quorum 值而卡死；需用 sentinel ckquorum 验证票数，再逐台执行 sentinel set 动态更新并确认生效。

哨兵日志里反复出现 missing+quorum，说明故障转移卡死，不是主库挂了，而是在线哨兵数不够投票门槛——改配置文件不重启、不手动同步，等于没改。

哨兵日志报 missing+quorum 怎么快速确认问题

这个错误信号明确指向法定票数不足。它不是偶然日志，而是持续性阻塞状态。

• 执行 redis-cli -p 26379 SENTINEL ckquorum mymaster，返回 ERR 就坐实了问题；返回 OK 则说明当前票数够，得查别的原因（比如从库全部不可用）
• SENTINEL sentinels mymaster 返回的哨兵数量，才是真实参与投票的节点数，别数进程或容器个数
• 注意：即使所有哨兵进程都在，如果某台网络隔离（比如只和部分哨兵互通），ckquorum 仍可能返回 OK，但实际无法达成共识

quorum 值改了但不生效的常见原因

哨兵不会热加载 quorum 配置，只在初始化或收到其他哨兵 hello 消息时协商确认。

Redis Skill - 高性能缓存管理

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

下载

• 只改 sentinel.conf 文件里的 sentinel quorum mymaster 3，不重启哨兵进程，配置无效
• 正确做法是逐台执行：redis-cli -p 26379 SENTINEL set mymaster quorum 2（假设你部署了3个哨兵）
• 执行后立刻用 SENTINEL master mymaster 查看输出中的 quorum: 字段，确认是否已更新为新值
• 如果某台哨兵长期失联，它上次广播的 quorum 可能被缓存，新哨兵加入后需等待配置同步完成才能参与投票

哨兵启动失败伴随 +sdown master 日志怎么排查

一启动就报 +sdown master mymaster 192.168.x.x，本质是哨兵连不上主节点，不是主库真宕机。

• 先用 redis-cli -h 192.168.x.x -p 6379 ping 确认主库是否可连；再用同样命令从哨兵所在机器直连主库 IP，排除网络策略或防火墙拦截
• 检查哨兵配置中 sentinel monitor mymaster 后面的 IP 和端口是否写错，尤其注意是否误用了 127.0.0.1 ——哨兵和主库不在同一台机器时，必须填真实 LAN IP
• 确认主库 redis.conf 中 bind 配置允许该 IP 访问（比如 bind 0.0.0.0 或显式列出哨兵所在网段）
• 检查主库是否启用了 protected-mode yes 且没配 bind 或 requirepass，这种组合会导致哨兵连接被拒绝

哨兵日志里频繁出现 connect timeout 或 connection refused

这类底层连接错误，通常暴露的是网络或权限问题，而不是哨兵逻辑本身异常。

• 用 telnet 192.168.x.x 6379 测试从哨兵机器到主库的 TCP 连通性；不通就查防火墙（iptables -L）、安全组、SELinux 策略
• 哨兵默认用客户端端口 +1000 作为集群通信端口（如主库监听 6379，则哨兵尝试连 16379），确认该端口在主库机器上已开放
• 检查哨兵运行用户是否有权读取 sentinel.conf 和写入日志路径；权限不足时，哨兵可能静默失败或只报模糊错误
• 如果使用 Docker，确保容器间网络互通，且宿主机或容器内没有 bind 127.0.0.1 这类限制

真正容易被忽略的点是：哨兵之间、哨兵与 Redis 实例之间的通信是双向的，任何一端的 bind、防火墙、网络策略都可能单向阻断；而日志往往只反映“我连不上”，不告诉你“对方根本没监听”或“对方拒绝了我”。