sentinel.conf 怎么配
哨兵的设计哲学是配置极简、运行期自发现：你只需要在配置里声明「监控哪个主库、判定下线需要几票」，其余从库名单、其他哨兵成员都由哨兵自己在运行时发现并回写进配置文件。因此部署的关键动作有三个：写一份最小配置、以显式路径启动、保证该文件对运行用户可写。配置文件路径必须在启动命令中给出，哨兵不会去默认位置寻找。
基本信息
| 必填项 | sentinel monitor <master-name> <ip> <port> <quorum> |
|---|---|
| 监听端口 | port 26379 |
| 工作目录 | dir /var/lib/redis，用于运行期写入 |
| 启动命令 | redis-sentinel /etc/redis/sentinel.conf |
| 文件权限 | 需对运行用户可写，运行期会自动追加从库与哨兵信息 |
典型使用场景
- 为单套主从配置三个哨兵，分别部署在三个故障域，避免整机故障同时损失投票节点
- 多套主从共用哨兵集群：在同一份配置里写多条 monitor 行，各自独立命名与设置票数
- 接入已有监控体系：哨兵配置写在配置管理里统一分发，运行期回写内容不纳入版本管理
- 从测试环境复制到生产：只改 monitor 行的地址与 quorum，其余参数按规模微调
- 灰度阶段先部署一个哨兵观察判定行为，确认阈值合理后再补齐到三节点
最小可用配置
最小可用配置
port 26379
dir /var/lib/redis
sentinel monitor mymaster 10.0.0.11 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1启动与注册为服务
启动与注册为服务
redis-sentinel /etc/redis/sentinel.conf
# 等价写法：
redis-server /etc/redis/sentinel.conf --sentinel
chown redis:redis /etc/redis/sentinel.conf # 运行期需要回写
systemctl status sentinel # 以 systemd 托管时确认工作目录与用户
redis-cli -p 26379 PING # 应返回 PONG常用参数含义
| 参数 | 含义 | 取值建议 |
|---|---|---|
| monitor | 被监控主库名称、地址与 quorum | 名称用业务可读的短标识 |
| down-after-milliseconds | 多久无响应判为主观下线 | 按链路抖动基线设置，常见 5 到 10 秒 |
| failover-timeout | 单次故障转移的超时与重试间隔 | 需大于从库完成同步的耗时 |
| parallel-syncs | 切换后同时向新主库同步的从库数 | 设为 1 可避免新主库被同步流量打满 |
哨兵运行期会改写自己的配置文件：发现从库后写入 slave 行，发现其他哨兵后写入 sentinel 行，还会记录当前的 epoch 与切换结果。因此配置文件不能挂成只读，也不要把运行期回写的内容当成人工配置随意清理，否则重启后哨兵认知会与真实拓扑脱节。
多套主库共用一个哨兵集群时，每个 master 名称必须唯一且各哨兵配置一致。名称冲突或 quorum 设置不一致会出现「部分哨兵认为已下线、部分不认」的僵局，切换无法推进且日志里缺少明显报错。