failover-abort-not-elected 表示哨兵发起故障转移但因票数不足未选出新主；根本原因是部分哨兵未参与投票，常见于网络不通、配置不一致、从节点不可达或时钟不同步。
failover-abort-not-elected 日志说明什么
这条日志表示哨兵已发起故障转移（+try-failover），但最终没能选出新主——不是没尝试，是投票环节彻底失败。它和 +failover-abort-no-good-slave（没健康从库）或 +failover-abort-not-permitted（权限/配置禁止）性质不同，核心卡点在「票数不够」。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
为什么 SENTINEL ckquorum 显示 OK 却仍 abort
因为 SENTINEL ckquorum 只检查「活着的哨兵数 ≥ 配置的 quorum 值」，但它不验证这些哨兵是否：
• 实际能互相通信（比如阿里云内网 IP 不通，26379 端口被安全组拦截）
• 持有完全一致的 sentinel monitor 配置（某台哨兵缓存了旧 master 地址或端口）
• 能连上所有从节点（SENTINEL slaves mymaster 返回为空或连接拒绝，会导致投票中途退出）
• 时钟同步正常（NTP 偏移 > 5s 可能导致 hello 消息被丢弃，视图分裂）
如何快速定位是不是选票数问题
执行以下三步，顺序不能错：
• 连任意一台哨兵，运行 SENTINEL masters，确认 num-sentinels 和 quorum 字段值
• 对同一 master 执行 SENTINEL ckquorum mymaster，返回 OK 才继续
• 再执行 SENTINEL sentinels mymaster，看返回的哨兵列表是否完整、IP 和端口是否可连（用 telnet ip 26379 测试）
如果第三步返回少于 num-sentinels 条记录，或其中某条记录的 flags 含 disconnected，问题就在这里——它们根本没参与投票。
quorum 设为 1 就一定能成功？不一定
设 quorum 1 确实绕过了多数派协商，但会暴露更底层的问题：
• 如果唯一在线的哨兵连不上任何从节点（比如从库防火墙开着、protected-mode yes 且没配 bind），它会直接打出 -failover-abort-no-good-slave
• 如果该哨兵自身配置里 sentinel monitor 的 master 地址写错，它压根不会触发 +try-failover
• 多数场景下，quorum 1 是临时排障手段，不可长期使用——它等于放弃容错能力，单点哨兵故障即雪崩
真正要盯住的，是 SENTINEL sentinels mymaster 输出里每条记录的 last-ping-reply 和 last-pong-reply 时间戳差值。超过 5000ms 就说明通信链路异常，比调小 quorum 重要得多。
