SENTINEL RESET 仅清空当前哨兵内存中指定主节点的从节点缓存、主观下线标记和投票记录，不处理哨兵节点生命周期或配置文件；离线哨兵需手动从其他哨兵的 sentinel.conf 中删除 known-sentinel 并重载配置或重启。
SENTINEL RESET 不是删除节点，而是清空哨兵内存里的“已知从节点缓存”
哨兵不会自动下线失效的 Sentinel 节点，因为 SENTINEL RESET 本身就不处理哨兵节点的生命周期管理——它只作用于主节点监控上下文。所谓“失效的 Sentinel 节点”，比如某台机器宕机、IP 变更或端口关闭后仍被其他哨兵记在 SENTINEL SENTINELS mymaster 列表里，这种残留状态不是靠 RESET 清理的。
真正该用的命令是 SENTINEL REMOVE-FAILED-MASTER（针对已 odown 且无主的 master）或直接重启/停掉那台离线哨兵进程。而 SENTINEL RESET mymaster 只做一件事：清空当前哨兵内存中关于 mymaster 的从节点列表、主观下线标记、投票记录等运行时状态，不碰哨兵节点自身拓扑。
为什么执行了 SENTINEL RESET 还能看到离线从节点
常见现象：执行 redis-cli -p 26379 sentinel reset mymaster 后立刻查 SENTINEL slaves mymaster，那个早就关机的 192.168.1.100:6380 还在返回结果里。
- 哨兵重发现有延迟，默认每 10 秒轮询一次，
RESET后需等至少一轮完整周期（建议等 30 秒再查） -
RESET不广播，只影响当前连接的哨兵实例；集群中每个哨兵都得单独执行一遍 - 若该哨兵日志里没出现
+reset-master行，说明命令没生效——可能是master-name拼错，或这台哨兵压根没配置过这个主节点（ERR unknown master name）
SENTINEL RESET 和哨兵配置文件 sentinel.conf 完全无关
sentinel.conf 是启动快照，仅用于初始化加载；所有运行时状态（包括哪些从节点在线、谁被标记为 s_down、quorum 投票结果）都存在内存中，并通过 Gossip 协议在哨兵间同步。所以：
-
SENTINEL RESET不会修改、重写或删除sentinel.conf中任何一行 - 删掉配置文件里的
sentinel monitor行再 reload，效果和RESET完全不同：前者让哨兵彻底停止监控该主节点，后者只是刷新认知 - 如果你发现某个哨兵反复尝试连一个已下线的从节点并刷屏
Connection refused，那大概率是没对所有哨兵执行RESET，或者旧节点还在其他哨兵的内存缓存里没被清理
真正要下线一台哨兵节点，你得人工干预
哨兵集群没有自动剔除离线哨兵节点的机制。当一台哨兵机器永久下线（比如云主机释放、物理机报废），其他哨兵仍会持续向它发 Gossip 消息，直到超时失败，日志里不断刷 Connection refused 或 timeout。
正确做法是：
- 确认该哨兵确实不再恢复，然后手动从所有其他哨兵的
sentinel.conf中删掉对应sentinel known-sentinel行（如果有） - 对每个存活哨兵执行
CONFIG REWRITE（需提前在redis.conf中放开config-command CONFIG权限） - 或更稳妥地：重启所有存活哨兵，让它们重新基于当前
sentinel monitor配置自发现其他哨兵，跳过已不可达节点
别指望 SENTINEL RESET 替你完成这件事——它只管主从拓扑的“记忆刷新”，不管哨兵自身的成员管理。
