把运行态写回配置文件
哨兵在内存里维护着一份运行状态：被监视的主库地址、已知副本列表、当前认定的主库、故障转移记录等。这份状态会在拓扑变化时自动重写到 sentinel 配置文件，Sentinel 也提供 SENTINEL FLUSHCONFIG 手工触发一次固化，把内存中的状态立即落盘。手工改过拓扑、用脚本调过参数、或者怀疑文件与运行态不一致时，用它对齐。命令生效的前提是配置文件的属主对哨兵进程可写，容器里挂成只读就必然失败。
基本信息
| 命令 | SENTINEL FLUSHCONFIG |
|---|---|
| 默认端口 | 26379 |
| 作用对象 | 哨兵配置文件（sentinel.conf） |
| 前置条件 | 配置文件对哨兵进程可写 |
| 配套命令 | SENTINEL MASTERS / SENTINEL REPLICAS |
| 生效范围 | 仅当前这一个哨兵节点 |
| 实测方式 | 对比文件修改时间与内容 |
典型使用场景
- 手工执行过 SENTINEL MONITOR 之类的运行期变更后，确认状态已经落盘
- 运维脚本批量改过哨兵参数，需要一次性固化避免遗漏
- 重启哨兵之前先固化，防止重启后拓扑回退到旧地址
- 容器或配置管理工具接管过 sentinel.conf，校验运行态与文件是否一致
- 巡检例程中定期固化并留档，作为拓扑变更基线
- 演练故障转移之后，把新拓扑固化并核对文件内容
固化与核对
固化与核对
redis-cli -p 26379 SENTINEL FLUSHCONFIG # 把当前状态写回配置文件
redis-cli -p 26379 SENTINEL MASTERS # 查看被监视主库列表
redis-cli -p 26379 SENTINEL REPLICAS mymaster # 查看该主库的副本
redis-cli -p 26379 SENTINEL GET-MASTER-ADDR-BY-NAME mymaster
redis-cli -p 26379 INFO sentinel # 概览哨兵自身状态
ls -l /etc/redis/sentinel.conf # 确认可写与修改时间不一致的后果与处理
| 场景 | 表现 | 处理 |
|---|---|---|
| 故障转移后未落盘 | 重启哨兵回到旧主库地址 | 固化后核对文件内容 |
| 容器只读挂载 | 固化失败或重启即回退 | 改为可写挂载或由外部渲染 |
| 配置管理覆盖文件 | 工具渲染把哨兵写入覆盖 | 把哨兵写入纳入回读逻辑 |
| 只固化单节点 | 各哨兵文件内容不一致 | 逐节点固化并比对 |
哨兵在拓扑变化时通常会自动重写配置，FLUSHCONFIG 的价值在于「立刻」和「可核对」，不是唯一的落盘途径。
容器化部署时，配置文件由 ConfigMap 之类只读资源挂载，哨兵无法写回；这种情况要让配置来源能反映真实拓扑，否则重启即回退。
固化只影响执行命令的那个哨兵节点，多节点部署要逐台执行并比对文件差异。