哨兵日志怎么读
一次故障切换的全过程都写在哨兵日志里：主观下线、客观下线、开始切换、选定并提升从库、切换完成。排障时按时间线通读日志，比反复猜测快得多；多哨兵部署时还要注意配置纪元，以多数派收到的通知为准。
基本信息
| 日志位置 | 由哨兵配置中的日志文件参数指定 |
|---|---|
| 事件格式 | 以加号或减号开头的事件名加对象与地址 |
| 关键事件 | 主观下线、客观下线、开始切换、提升从库、切换完成 |
| 配置纪元 | 每次切换递增，用于多哨兵之间比较新旧 |
| 轮转要求 | 必须配置日志轮转，否则长期运行会写满磁盘 |
典型使用场景
- 切换复盘：按时间线还原从故障发现到切换完成的每一步
- 判断切换真伪：确认是否真的完成了切换，而不是只发生了告警
- 多哨兵一致性核对：比较各节点日志，确认多数派观点一致
- 切换失败排查：定位是票数不足、从库不可用还是切换被中止
- 容量评估：通过切耗费时长评估高可用体系是否满足恢复目标
关键日志行
关键日志行
# 主观下线：单个哨兵认为主库不可达
# +sdown master mymaster 10.0.0.10 6379
# 客观下线：达到票数后判定主库真正不可用
# +odown master mymaster 10.0.0.10 6379 #quorum 2/2
# 开始切换与选定新主库
# +try-failover master mymaster 10.0.0.10 6379
# +selected-slave slave 10.0.0.11:6379
# 提升并完成切换
# +promoted-slave slave 10.0.0.11:6379
# +switch-master mymaster 10.0.0.10 6379 10.0.0.11 6379
grep -E "switch-master|odown|try-failover" /var/log/redis/sentinel.log | tail -20事件逐项读法
| 事件 | 含义 | 后续动作 |
|---|---|---|
| 主观下线 | 单一哨兵判定节点不可达 | 等待其他哨兵是否认同 |
| 客观下线 | 票数达标确认主库不可用 | 准备进入切换流程 |
| 开始切换 | 选出竞选从库并发起切换 | 观察是否出现中止事件 |
| 提升从库 | 从库被提升为新主库 | 确认新主库可写 |
| 切换完成 | 新旧地址同时给出 | 核对客户端是否已刷新地址 |
| 切换中止 | 票数不足或重试耗尽 | 检查哨兵数量与网络 |
日志中同一时刻不同哨兵的记录会略有差异，判断切换事实以多数派收到的切换完成通知为准。
哨兵日志不配轮转：长期运行后磁盘被写满，进而影响同一主机上的其他服务。