哨兵配置不会自动同步，必须执行sentinel flushconfig才能将运行时修改的配置持久化到磁盘；否则重启后所有变更（如sentinel set、reset、故障转移更新）均丢失，导致节点间配置不一致。
哨兵节点的配置不会自动同步，sentinel flushconfig 是唯一能强制把当前内存中生效的配置写入磁盘的命令——不执行它，重启后所有运行时变更（比如 sentinel reset、sentinel set 修改的参数）都会丢失。
为什么哨兵配置容易不一致
哨兵节点之间不共享配置文件，也不通过 gossip 同步 config。每个哨兵只维护自己的 sentinel.conf，且只有启动时加载一次。运行时所有配置变更（如故障转移后的主节点更新、sentinel set mymaster down-after-milliseconds 3000）都只存在内存里。
常见错误现象：
- 手动执行
sentinel set调整了超时时间，但哨兵重启后恢复成旧值 - 故障转移完成后，新主节点信息没写进配置，下次启动时仍指向已下线的老主节点
- 多个哨兵节点配置文件内容不同，导致 quorum 判定逻辑混乱
什么时候必须执行 sentinel flushconfig
只要配置在运行时被修改过，且希望它持久化，就必须手动触发。不是“建议”，是“必须”。
典型场景包括：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
sentinel set修改了任意参数（如sentinel set mymaster failover-timeout 90000） - 执行了
sentinel reset mymaster清除了故障状态和历史信息 - 哨兵完成一次故障转移后，需要固化新的主节点地址和从节点拓扑
- 批量运维脚本中修改配置后，需确保所有哨兵节点配置落地
sentinel flushconfig 的实际行为与限制
它只是把当前哨兵进程内存中的完整配置 dump 到本地 sentinel.conf 文件（覆盖写），不涉及网络通信、不通知其他哨兵、不校验语法。
关键注意事项：
- 该命令无返回值，成功即静默；失败通常因磁盘满或权限不足，此时日志会报
Failed to open config file for writing - 它不会重载配置，也不会影响正在运行的监控逻辑——只是“存盘”，不是“生效”
- 如果哨兵是以 systemd 或 supervisor 管理，需确认其配置文件路径是否与
sentinel.conf实际位置一致（比如有的部署在/etc/redis/sentinel.conf，有的在/usr/local/etc/sentinel.conf） - 不能替代配置管理工具（如 Ansible），多节点部署时仍需单独登录每台机器执行，或封装为批量脚本
配置一致性真正依赖的是人工+流程，不是机制
Redis 哨兵本身没有配置同步协议，sentinel flushconfig 只解决单点落盘问题。跨节点一致性只能靠外部手段保障：
- 所有哨兵节点应使用同一份初始
sentinel.conf模板部署 - 运行时修改必须走统一运维通道（如封装好的 CLI 工具），并在每台机器上顺序执行
sentinel set+sentinel flushconfig - 定期校验各节点
sentinel.conf文件 md5 是否一致，尤其关注sentinel monitor、quorum、down-after-milliseconds这几行 - 避免直接编辑配置文件后 reload —— 哨兵不支持 SIGHUP，改完文件不重启就无效，重启又可能丢掉运行时状态
最容易被忽略的一点：sentinel flushconfig 不保证“最终一致”，它只保证“本机这次改的没丢”。三台哨兵，少执行一次，那台就永远掉队。
