哨兵为什么需要清单
哨兵的故障大多不是「进程挂了」，而是「以为被保护着，其实保护不了」：票数凑不够、脚本没装、公告地址不可达、从来没人真正演练过切换。把上线前和周期巡检要看的东西固化成清单，人员轮换时也不容易漏项。
基本信息
| 拓扑要求 | 3 个以上哨兵，分布在不同故障域 |
|---|---|
| 配置项 | quorum、认证、公告地址、日志落盘 |
| 运行检查 | CKQUORUM 结果与事件日志 |
| 验证项 | 定期演练切换并留存记录 |
典型使用场景
- 新上线一套哨兵时逐项对照配置
- 季度巡检核对拓扑与票数是否仍然合理
- 告警失效排查时确认通知链路是否还能工作
- 人员交接时作为知识传递的载体
- 切换演练前先跑一遍清单确认前置条件
巡检命令
巡检命令
# 票数与多数派是否还能满足客观下线判定
redis-cli -p 26379 SENTINEL CKQUORUM mymaster
# 主库地址、角色标记与下线判定参数
redis-cli -p 26379 SENTINEL MASTERS
# 其他哨兵是否都在名册里、地址是否可达
redis-cli -p 26379 SENTINEL SENTINELS mymaster
# 结果留档，便于与上一期对比发现配置漂移
redis-cli -p 26379 SENTINEL MASTERS | tee /var/log/redis/sentinel-check-$(date +%F).log检查项目
| 检查项 | 判断标准 | 漏项的后果 |
|---|---|---|
| 哨兵数量与分布 | 3 个以上且跨故障域 | 单点故障即失去仲裁能力 |
| quorum 与多数派 | 能凑出多数票选出 leader | 永远无法完成切换 |
| 认证配置 | 实例有密码时已配 auth-pass | 哨兵能看到实例却读不了状态 |
| 公告地址 | 各哨兵输出地址互相可达 | 选举与客户端连接失败 |
| 日志与告警 | 日志落盘、通知脚本已部署 | 事件无人知悉，故障静默 |
| 演练记录 | 有近期演练与耗时数据 | 真故障时才发现流程不通 |
清单要配留档才有价值：把每期巡检输出存下来，下一期对比就能看出配置漂移与拓扑变化，而不是每回都从零判断。
只监控「进程还在不在」等于没查：进程活着但票数不足、脚本丢失、公告地址配错，真出故障时照样不会切换。