SENTINEL RESET 仅重置本节点对指定 master 的本地视图（如已知哨兵、主观下线状态等），不广播至其他哨兵，也不清除持久化配置中的 known-sentinel 记录，故无法自动清理全集群残留状态。
哨兵节点挂掉后，残留的 sentinel known-sentinel 记录和过期的主从元数据不会自动消失，必须手动清理，否则会影响新哨兵加入、故障转移判断甚至导致配置不一致。
为什么 SENTINEL RESET 不能直接清空所有历史状态
SENTINEL RESET 只重置本节点对指定 master 的本地视图（包括已知哨兵列表、主观下线状态、failover 状态等），但不会广播给其他哨兵，也不影响其他哨兵节点上的记录。如果只是单点执行，其他哨兵仍保留旧的 known-sentinel 条目或错误的 master-down-after-milliseconds 配置，后续选举可能失败或延迟。
- 执行
SENTINEL RESET <master-name>后，本节点会丢弃对该 master 的全部哨兵发现记录和投票历史 - 但其他哨兵节点仍会通过 gossip 持续广播已下线哨兵的 ID，只要它还在某个节点的
sentinel known-sentinel列表里，就可能被重新“复活” - 若挂掉的是 quorum 中的关键哨兵（比如曾主导过一次 failover），其 epoch 和 config-epoch 可能残留在部分哨兵的持久化配置中，引发版本冲突
如何安全删除已下线哨兵的 known-sentinel 记录
必须在所有存活哨兵节点上逐个执行 SENTINEL REMOVE，且顺序不能错：先删哨兵自身记录，再删它曾监控的 master 下的关联条目。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 连接任一存活哨兵：
redis-cli -p 26379 - 查出目标哨兵 ID：
SENTINEL SENTINELS <master-name>，找到已宕机哨兵的runid（如7f8a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a） - 对每个存活哨兵，执行：
SENTINEL REMOVE <runid>—— 注意不是RESET，这个命令会从本节点的known-sentinel表中彻底移除该 ID - 执行后等待 2–3 秒，再用
SENTINEL SENTINELS <master-name>验证是否消失；若仍有残留，说明该哨兵尚未收到 gossip 同步，需重复执行或检查网络连通性
清理失败时的典型错误现象与排查点
常见表现是 SENTINEL REMOVE 返回 (integer) 0 或静默无响应，本质是目标 runid 并未存在于当前哨兵的 known-sentinel 列表中——但它可能藏在别的地方。
-
SENTINEL MASTER <master-name>输出中num-other-sentinels不减，但SENTINEL SENTINELS已看不到该哨兵 → 它可能还卡在某个哨兵的sentinel pending-scripts或未 flush 的配置缓存里 - 哨兵日志持续打印：
Ignoring SENTINEL REMOVE of unknown sentinel→ 说明你用的runid错了，或该哨兵从未被本节点发现过（比如部署在隔离网络段） - 重启哨兵后旧哨兵又出现 → 检查
sentinel.conf文件是否手动写入了sentinel known-sentinel行，这类行不会被REMOVE清除，必须手工删掉并SENTINEL CONFIG REWRITE
真正麻烦的不是删不掉，而是删得不干净：一个残留的 known-sentinel 可能让新哨兵反复尝试握手、拉取配置，拖慢整个集群的故障检测收敛速度。动手前务必确认目标哨兵确实永久离线，而不是临时失联。
