领导者是怎么选出来的
主库被判定为客观下线后，哨兵们要选出一个领导者来执行这次故障转移。过程借用 Raft 的思路：发起者把配置纪元加一并向其他哨兵请求投票，谁先拿到多数派票谁当选，落选者等待一段时间后可以再次发起。当选者负责挑选新主库、指挥其余副本改指向，最后把新配置广播出去，其余哨兵据此同步状态。
基本信息
| 触发条件 | 主库被判定为客观下线 |
|---|---|
| 投票依据 | 配置纪元与多数派同意 |
| 结果 | 一个领导者执行切换，其余哨兵跟随 |
| 重试机制 | 落选者等待一段时间后可重新发起 |
| 日志标记 | 投票、当选、尝试切换等事件标记 |
典型使用场景
- 切换失败需要判断卡在哪一步，先确认是否选出过领导者
- 哨兵数量不足或互相不通导致选举反复失败，需要快速定位
- 演练时验证选举与切换是否按预期完成，记录耗时
- 排查日志里纪元不断递增的震荡现象
- 为哨兵集群设计告警时明确哪些事件代表异常
观察选举过程
观察选举过程
grep -iE 'vote-for-leader|new-epoch|switch-master' /var/log/redis/sentinel.log | tail -20
redis-cli -p 26379 SENTINEL MASTERS | grep -E 'name|flags'
redis-cli -p 26379 SENTINEL CKQUORUM mymaster # 检查是否满足判定所需的票数
redis-cli -p 26379 SENTINEL SENTINELS mymaster # 哨兵之间是否互相可见日志标记与含义
| 标记 | 含义 | 需要关注的情况 |
|---|---|---|
| 纪元更新 | 配置版本号被提升 | 频繁递增说明存在拓扑震荡 |
| 投票事件 | 某哨兵投票给某个候选 | 长期无投票记录说明哨兵间不通 |
| 尝试切换 | 选举出的领导者开始执行 | 反复出现说明切换未完成 |
| 切换完成 | 新主库已确定并广播 | 耗时明显偏长需要复盘 |
选举是多哨兵之间的自动协调动作，不需要人工干预；反复选举失败通常指向哨兵之间网络不通或哨兵数量不足。
哨兵两两之间也要能互相通信，防火墙只放行应用侧到业务端口的链路是常见漏配，结果就是每个哨兵都只能看到自己。