哨兵无法触发故障转移，主因是quorum配置不合理：值大于当前可通信哨兵数（如设3但仅2台在线），导致SENTINEL ckquorum返回ERR missing+quorum，日志仅见+sdown而无+odown；quorum须≤实际互通哨兵数，推荐⌊N/2⌋+1且需通过SENTINEL set命令运行时生效并验证。
哨兵模式无法触发自动故障转移，八成是 quorum 值设得不合理——不是太大就是太小，或者根本没生效。
quorum 值大于当前在线哨兵数，直接卡死在 missing+quorum
这是最常见、也最容易被忽略的硬性阻塞点。只要 quorum 设为 3，而实际能互相通信的哨兵只有 2 台，故障转移流程连第一步都迈不出去。
-
SENTINEL ckquorum mymaster返回ERR missing+quorum就是铁证 - 日志里反复出现
+sdown master mymaster，但始终没有+odown，说明共识卡在投票门槛上 - 执行
redis-cli -p 26379 SENTINEL sentinels mymaster看返回几条记录，不是看进程数或容器数——网络不通、防火墙拦截、配置未同步都会导致“逻辑上线”但“物理失联” - quorum 必须 ≤ 当前可通信哨兵数；推荐值是 ⌊N/2⌋ + 1（N 为部署总数），比如 3 台哨兵就设 2，5 台设 3；设成 1 容易误切，设成 N 则单点失联即瘫痪
quorum 在配置文件里改了，但根本没生效
哨兵不热重载 quorum，改完 sentinel.conf 不等于改完了。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 启动失败场景：如果
sentinel monitor行末尾的quorum写成"2"、2.0或空格，redis-sentinel 直接退出，报Invalid argument 'quorum' - 运行中修改必须用命令：
redis-cli -p 26379 SENTINEL set mymaster quorum 2，逐台执行，不能只改一台 - 验证是否生效：执行
redis-cli -p 26379 SENTINEL master mymaster，看输出里的quorum字段，它显示的是当前协商值，不是配置文件原始值 - 别跳过
--test-conf：改完配置先跑redis-sentinel /path/to/sentinel.conf --test-conf，语法错当场暴露
sentinel monitor 配置不一致，哨兵在“监控不同的主库”
哨兵之间靠 hello 消息同步 sentinel monitor 规则。如果某台哨兵没收到完整广播，它眼里就没有这个主节点，自然不会参与投票。
- 现象：
SENTINEL masters在不同哨兵上输出不一致——有的返回空，有的返回fail，有的压根没mymaster这个名字 - 原因包括：新哨兵刚启动还没等够 30 秒（默认
default-down-after-milliseconds的两倍）就遭遇故障；某台哨兵长期离线后重启，缓存了旧 monitor 配置 - 修复动作：不能只依赖广播，必须手动强制刷新——在每台哨兵上执行
SENTINEL monitor mymaster 192.168.1.100 6379 2（地址和端口务必统一，别混用 IP 和域名） - 检查是否同步完成：执行
SENTINEL sentinels mymaster，确认所有哨兵的flags字段不含disconnected，且last-ok-ping-reply时间差在 1 秒内
真正决定能否选出新主的，不是你写了几个哨兵，而是它们能不能在 26379 端口上稳定握手、对同一个 mymaster 达成一致、并且凑够 quorum 张有效票——这三件事缺一不可。网络分区、NTP 偏移、protected-mode 拒绝连接，这些看似无关的配置，都会让 quorum 形同虚设。
