SENTINEL RESET 仅清空哨兵内存中指定主节点的“已知从节点/故障节点”缓存，不删除配置、不修改拓扑、不广播至其他哨兵，需对集群每台哨兵单独执行并等待下轮定时任务（默认10秒）重新发现。
SENTINEL RESET 命令到底重置什么
SENTINEL RESET 不是删除节点配置，也不是修改哨兵拓扑，它只清空哨兵内存里关于指定主节点的“已知从节点/故障节点”缓存。哨兵自己不会主动探测所有历史记录过的实例，而是依赖之前 SENTINEL MONITOR 或自动发现产生的状态快照；一旦某个 master-name 下的实例长期失联（比如下线、IP变更、端口关闭），它的信息会滞留在哨兵的内部字典中，表现为 SENTINEL slaves <master-name> 仍列出已不存在的 IP:port，或 SENTINEL failover-status 显示异常状态。
实操建议：
- 必须指定准确的
master-name，不能只写 IP 或别名 —— 哨兵按这个名字索引整个监控上下文 - 命令执行后不会立即刷新从节点列表，需等待下一轮哨兵定时任务（默认 10 秒）重新扫描或收到其他哨兵的通告
- 如果该
master-name当前没有活跃主节点，SENTINEL RESET依然生效，但后续若有人重新SENTINEL MONITOR同名主节点，旧缓存不会复活
为什么 SENTINEL RESET 后还是看到离线节点
常见错误现象：执行了 SENTINEL RESET mymaster，再查 SENTINEL slaves mymaster，结果那个早就关机的 192.168.1.100:6380 还在返回结果里。
原因很直接：哨兵没来得及重发现，或者别的哨兵节点还没同步这个重置动作。哨兵集群不是强一致系统，RESET 只作用于当前连接的哨兵实例，不广播给其他哨兵 —— 每个哨兵都得单独执行一遍。
实操建议：
- 对集群中每个哨兵节点都运行一次
SENTINEL RESET mymaster，别漏掉任何一台 - 检查哨兵日志是否有
+reset-master行，确认命令被接受；若出现ERR unknown master name，说明名字拼错或该哨兵根本没配置过这个主节点 - 等至少 30 秒后再查
SENTINEL slaves mymaster，避免因轮询间隔导致误判
和 SENTINEL REMOVE-FAILED-MASTER 的区别在哪
SENTINEL REMOVE-FAILED-MASTER 是彻底删掉一个已被判定为客观下线（odown）且当前无主节点的失败主节点定义，包括它的所有从节点、哨兵投票记录、故障转移历史。而 SENTINEL RESET 更轻量，它保留主节点监控定义本身，只清理附属状态。
使用场景差异明显：
- 用
SENTINEL REMOVE-FAILED-MASTER mymaster：主节点已永久废弃，你也不打算再用这个名字监控新实例 - 用
SENTINEL RESET mymaster：主节点还在用，只是想甩掉一堆“幽灵从节点”，比如批量替换从库后旧地址残留 - 注意：
REMOVE-FAILED-MASTER要求目标主节点当前处于failover-aborted或no-failover状态，否则报错ERR Master is not in failed state
重置后哨兵会不会自动重新发现从节点
不会自动发现。哨兵只通过三种方式获知从节点：1）主节点的 INFO replication 返回的 slaveX 字段；2）其他哨兵发来的 sentinel is-master-down-by-addr 通告；3）你手动执行 SENTINEL REPLICATE（极少用）。RESET 后，哨兵会像刚启动一样，从主节点拉取最新从库列表 —— 所以前提是主节点必须在线、响应正常、且 INFO replication 输出正确。
实操建议：
- 确保主节点 Redis 进程存活、端口可达、未启用
slave-announce-ip错误配置（比如写死内网地址却暴露在公网） - 如果主节点也重启过，观察
SENTINEL masters中对应项的num-slaves是否缓慢上升，这是正常重发现过程 - 别指望
RESET解决网络隔离问题：如果哨兵根本连不上主节点，它连INFO都拿不到，自然无法更新从节点列表
真正容易被忽略的是哨兵之间的配置同步延迟和主节点 INFO 接口的准确性 —— 很多时候你以为清掉了缓存，其实是主节点自己没报对从库，或者哨兵之间还没交换完状态。
