哨兵日志反复出现 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、防火墙、网络策略都可能单向阻断；而日志往往只反映“我连不上”，不告诉你“对方根本没监听”或“对方拒绝了我”。
