重启时的启动顺序
机房整体重启后，启动顺序会直接影响哨兵的行为：应该先拉起数据实例（主库与从库），等它们加载完数据、主从握手完成，再启动哨兵。哨兵起得太早，会在实例还没就绪时判定下线，甚至触发一次完全没有必要的切换。
基本信息
| 推荐顺序 | 先数据实例，再哨兵 |
|---|---|
| 原因 | 避免在启动窗口内误判实例下线 |
| 大实例注意 | 加载数据可能持续数分钟 |
| 核对项 | SENTINEL MASTERS 的地址与角色标记 |
典型使用场景
- 机房维护后的整体重启编排
- 扩容或迁移后按角色依次拉起服务
- 排查「重启后为什么出现了两个主库」
- 把启动依赖写进容器编排的健康检查
- 演练断电恢复流程并记录各阶段耗时
按顺序拉起
按顺序拉起
# 第一步：确认数据实例就绪，且数据已加载完成
redis-cli -p 6379 PING
redis-cli -p 6379 INFO persistence | grep loading
# 第二步：确认主从角色与预期一致，重启后这里最容易错位
redis-cli -p 6379 INFO replication | grep -E 'role|connected_slaves'
# 第三步：数据实例就绪后再启动哨兵，并核对监控对象
redis-cli -p 26379 PING
redis-cli -p 26379 SENTINEL MASTERS启动核对
| 检查项 | 命令或依据 | 期望结果 |
|---|---|---|
| 实例存活 | PING | 返回 PONG |
| 加载完成 | INFO persistence 的 loading | 为 0，加载中不要启动哨兵 |
| 主从角色 | INFO replication 的 role | 与预期一致 |
| 哨兵监控对象 | SENTINEL MASTERS | 地址与角色标记正确 |
| 票数可用性 | SENTINEL CKQUORUM | 能满足多数派 |
编排系统里把依赖写成显式的健康检查（实例加载完成后再拉起哨兵），比人工等待固定时间可靠得多；能用条件判断就不要用延时。
大实例加载数据可能持续数分钟，如果这段时间哨兵已经在跑，它可能把还没就绪的实例判为下线并触发切换，重启本身反而制造了一次故障。