哨兵故障切换流程是什么
哨兵的切换是一条完整链路：单个哨兵先在 down-after-milliseconds 内收不到响应，把它标记为主观下线 sdown；当达到 quorum 个哨兵都认为它挂了，才升级为客观下线 odown；接着哨兵之间选举出领头者，由它挑选合适的从库提升为新主，再把其他从库和恢复后的旧主重新指向新主，最后通过 Pub/Sub 事件通知客户端。
基本信息
| 关键配置 | down-after-milliseconds / failover-timeout / parallel-syncs / quorum |
|---|---|
| 判定阶段 | sdown 为单点视角，odown 为达到票数后的客观判定 |
| 选举要求 | 需要多数哨兵授权，因此哨兵数量应为奇数 |
| 选主顺序 | replica-priority 小者优先，其次复制 offset 大者，再次 runid 小者 |
| 通知方式 | Pub/Sub 的 +switch-master 等事件 |
典型使用场景
- 主库宕机自动切换：把人工介入时间压缩到秒级
- 故障演练：用停进程或阻塞端口模拟，观察整个切换链路
- 事件跟踪：订阅 +switch-master 与 +sdown 事件掌握每次变更
- 误判治理：down-after-milliseconds 设得过小时网络抖动就触发切换
- 优先级调整：给机器规格高的从库设更小的 replica-priority
- 切换后核对：确认所有从库都已指向新主，没有节点仍指向旧主
观察切换过程
观察切换过程
redis-cli -p 26379 SENTINEL master mymaster | grep -E 'flags|num-slaves|quorum'
redis-cli -p 26379 INFO sentinel
redis-cli -p 26379 PSUBSCRIBE '+switch-master' # 订阅主库变更事件
redis-cli -p 26379 PSUBSCRIBE '+sdown' '+odown' # 订阅下线判定事件
tail -f /var/log/redis/sentinel.log # 日志里能看到各阶段状态
redis-cli -p 26379 SENTINEL replicas mymaster # 切换后确认从库列表
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster # 客户端取值方式阶段读法
| 阶段 | 触发条件 | 动作 |
|---|---|---|
| sdown | 单个哨兵在超时时间内无响应 | 仅标记，不触发切换 |
| odown | 达到 quorum 个哨兵确认下线 | 进入故障转移流程 |
| 选举 | 哨兵之间需要多数派授权 | 选出领头哨兵 |
| 提升 | 领头哨兵挑从库执行主库提升 | 候选从库变为可写新主 |
| 重配 | 其余从库改指向新主 | 旧主恢复后也被降级为从库 |
从库挑选顺序：replica-priority（小者优先）大于复制 offset 大者，再大于 runid 小者；把重要机器 priority 调小可以影响切换结果。
切换期间存在短暂的写入真空：旧主未隔离时可能仍接受客户端写入，新主则从自己的数据开始服务；应确保应用支持主库变更事件并开启自动重连，必要时配合代理层统一地址入口。