sentinel ckquorum 返回 err 是最直接信号，表明当前可通信哨兵数不足 quorum 值，导致无法进入客观下线和故障转移流程；需立即检查 sentinel sentinels mymaster 输出数量、网络连通性及 quorum 动态配置是否生效。
SENTINEL ckquorum 返回 ERR 是最直接信号
看到日志里反复出现 missing+quorum 或 failover-abort-no-good-slave，第一件事不是查从库，而是跑 SENTINEL ckquorum mymaster。它不模拟选举，只干一件事：确认当前活着且能互相通信的哨兵数是否 ≥ 配置的 quorum 值。
常见错误现象：
-
SENTINEL ckquorum mymaster返回ERR并提示Quorum not reached，说明票数根本凑不够，后续所有流程都不会启动 - 哨兵进程数是 3，但
SENTINEL sentinels mymaster只返回 1 或 2 条记录——说明有哨兵被网络隔离，比如防火墙没开26379端口双向通信 -
quorum设为 3，但实际在线哨兵只有 2 个；或者部署了 4 台哨兵却设quorum 3，而其中一台因 NTP 时间偏移过大被其他哨兵拒绝握手
修复必须用 SENTINEL set mymaster quorum <n></n> 逐台执行，改配置文件 + SENTINEL RELOAD 不生效。Redis 3.2+ 支持该命令，执行后立刻在 SENTINEL master mymaster 输出中核对 quorum 字段是否更新。
slave 的 master_link_status:down 比你想象中更常见
failover-abort-no-good-slave 日志的真实含义不是“挑不出好 slave”，而是哨兵遍历完所有已知从节点后，一个都没通过基础健康检查——连复制链路都断着，自然不会参与投票。
别只信 SENTINEL masters 输出的 num-slaves，要逐台登录每个从节点，运行：
redis-cli -p 6379 INFO replication
重点盯这三行：
-
role:slave—— 必须是slave，不是master或unknown -
master_host和master_port—— 必须指向当前故障主节点，不能是nohost或0 -
master_link_status:up—— 关键！若为down，再看master_last_io_seconds_ago是否大于down-after-milliseconds（默认 30000），超时即被哨兵标记为不可用
常见诱因：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 从节点启用了
requirepass，但哨兵没配sentinel auth-pass，连接被拒绝后直接记为离线 - 从节点绑定了
bind 127.0.0.1，哨兵从其他机器无法建立 TCP 连接 - 防火墙或云安全组未放行从节点的 Redis 端口（如
6379）
日志级别设为 verbose 才能看到真实选举卡点
默认 loglevel notice 会过滤掉 +odown、+try-failover、+failover-state-select-slave 等关键事件。不调级别，等于蒙眼排障。
临时开启（重启失效）：
CONFIG SET loglevel verbose
永久生效：在 sentinel.conf 中加 loglevel verbose，再执行 SENTINEL RELOAD 或重启进程。注意生产环境排查完需调回 notice，避免日志爆炸。
重点关注这些日志线索：
- 只有
+sdown没有+odown→ quorum 不达标或哨兵间通信失败 - 反复出现
Failed to resolve master address→ 哨兵缓存了旧 master 地址，需执行SENTINEL RESET mymaster - 日志里
announce-ip写的是127.0.0.1或内网不可达地址 → 容器/K8s 环境下必须显式配置可被其他哨兵访问的真实 IP
选举慢往往卡在从节点筛选阶段而非投票本身
哨兵选主分两步：先选 leader 哨兵（Raft 式投票），再由 leader 筛选新主。后者才是耗时大头，尤其当多个从节点延迟接近、优先级相同、复制偏移量差异微小时。
leader 筛选逻辑严格按顺序执行：
- 排除
replica-priority 0的节点 - 排除
master_link_status:down的节点 - 选
replica-priority最高者 → 同优先级则比offset最大者 → offset 相同再比run_id字典序最小者
容易被忽略的细节：
-
down-after-milliseconds在哨兵和从节点上必须一致，否则从节点自己判定断连时间早于哨兵，导致master_link_status提前变down - 从节点设置了
replica-serve-stale-data no且主从断连后拒绝响应，哨兵可能误判其不可用 - DNS 名做 master 地址时，TTL 过长会导致哨兵长期缓存失效解析，建议用 IP 或短 TTL DNS
