SENTINEL RESET 仅清空哨兵内存中的从节点列表和故障缓存，不触发立即重发现；需逐台执行并等待10–30秒后查日志+reset-master及SENTINEL slaves确认。
SENTINEL RESET 只清内存缓存，不触发立即重发现
执行 SENTINEL RESET mymaster 后立刻查 SENTINEL slaves mymaster 还看到离线从节点，不是命令没生效，而是哨兵不会马上重新拉取主节点的 INFO replication。它只清空当前哨兵内存里的「已知从节点列表」和「故障节点缓存」，下一轮定时任务（默认 10 秒）才会主动去主节点抓新数据。
常见误操作是执行完 RESET 就立刻验证，结果误判为失败。真正可靠的判断依据是日志里有没有 +reset-master 行——有这条，说明命令已落地；没这条，说明 master-name 拼错或该哨兵根本没加载这个监控项。
必须对每台哨兵单独执行 RESET
哨兵之间不广播 RESET 操作，也不同步内存状态。你在 A 哨兵上执行了 SENTINEL RESET mymaster，B 和 C 哨兵完全不知情，它们各自的从节点缓存照旧挂着。漏掉任意一台，离线节点就还在那里。
实操建议：
- 用循环脚本逐台连接所有哨兵端口（如 26379），执行
SENTINEL RESET mymaster - 确认每台哨兵日志都出现
+reset-master - 等 10–30 秒后，再统一查
SENTINEL slaves mymaster输出是否一致且干净
RESET 前主节点必须在线且可连
如果主节点本身已宕机，RESET 虽然成功返回，但后续无法发起 INFO replication 请求，也就拿不到真实从节点列表——等于清了个寂寞。
更隐蔽的问题是：刚做完故障转移，哨兵内部状态机可能还在同步配置（比如正在广播新主地址、更新其他哨兵视图）。此时立刻 RESET，容易和 failover-state-wait-promotion 或 failover-state-reconf-slaves 阶段冲突，导致部分从节点“消失又重现”。
稳妥做法：
- 先用
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster确认主节点地址有效且能连通 - 若刚切完主，等至少 30 秒再执行 RESET
- 避免在
SENTINEL ckquorum mymaster返回ERR No quorum reached时强行 RESET
别把 RESET 和 flushconfig 搞混
SENTINEL RESET 是纯内存操作，不影响 sentinel.conf 文件；SENTINEL FLUSHCONFIG 则是把当前哨兵内存里所有 monitor 条目、auth 设置等强制刷回磁盘配置文件——这跟清理离线节点无关，反而可能覆盖你手动改过的配置。
最容易被忽略的是：有人看到离线节点还在，顺手执行了 SENTINEL FLUSHCONFIG，结果把其他正常监控项也刷丢了，或者把 sentinel auth-pass 写成了空值，导致后续无法连主从节点。
真正要做的只有两步：对每台哨兵逐个执行 SENTINEL RESET <master-name></master-name>，然后等 10–30 秒再验证。不需要 reload、不需要 flushconfig、不需要重启哨兵进程。
