按时间轴读日志
哨兵把关键状态变化全部写进日志，并给事件加上前缀符号：主观下线、客观下线、纪元更新、开始尝试切换、切换完成、主库切换通知等等。排查切换问题的正确姿势是按时间轴读这些标记：先找到第一个异常标记，再往后确认动作链是否完整，比从后往前逐条猜要高效得多，也更容易发现卡在哪一步。
基本信息
| 日志位置 | 配置文件中的日志路径，或标准输出 |
|---|---|
| 关键前缀 | 带符号的事件行，如主观与客观下线标记 |
| 阅读方式 | 先定位首个异常标记，再顺时间向后续读 |
| 常见异常 | 尝试切换反复出现说明切换失败 |
| 多节点视角 | 多台哨兵的日志要按时间对齐看 |
典型使用场景
- 切换没有发生或没有完成，需要确认卡在哪个阶段
- 复盘一次切换的完整耗时，为 SLA 评估提供数据
- 怀疑某个实例被误判下线，从日志里确认判定依据与时间点
- 排查主库地址反复漂移，找出触发源
- 把关键事件接入监控告警，日志配置需要保证长期留存
常用查看方式
常用查看方式
grep -E '\+|-|#' /var/log/redis/sentinel.log | tail -50 # 事件行集中在带符号的记录
grep -c 'try-failover' /var/log/redis/sentinel.log # 尝试切换的次数统计
grep -iE 'odown|sdown' /var/log/redis/sentinel.log | tail -20
tail -f /var/log/redis/sentinel.log # 演练时实时跟踪标记与应对
| 标记类型 | 含义 | 应对方向 |
|---|---|---|
| 主观下线 | 单个哨兵认为实例不可达 | 先确认是否网络抖动，可暂时观察 |
| 客观下线 | 达到票数的哨兵共同判定不可达 | 准备切换，检查副本可用性 |
| 尝试切换 | 领导者开始执行切换 | 频繁出现要查切换失败原因 |
| 主库切换通知 | 新主库地址已确定 | 核对应用侧指向是否同步更新 |
| 切换中止 | 本次切换被放弃 | 结合后续记录看是否重试或原因分支 |
日志只留标准输出且被进程重定向覆盖时，问题窗口的记录可能已经丢失，配置独立日志文件更稳。
单台哨兵的日志只能反映它的视角，判断谁先发起、谁在拖延，需要把多台哨兵的日志按时间对齐一起看。