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-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></master-name>，找到已宕机哨兵的 runid（如 7f8a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a）
• 对每个存活哨兵，执行：SENTINEL REMOVE <runid></runid> —— 注意不是 RESET，这个命令会从本节点的 known-sentinel 表中彻底移除该 ID
• 执行后等待 2–3 秒，再用 SENTINEL SENTINELS <master-name></master-name> 验证是否消失；若仍有残留，说明该哨兵尚未收到 gossip 同步，需重复执行或检查网络连通性

清理失败时的典型错误现象与排查点

常见表现是 SENTINEL REMOVE 返回 (integer) 0 或静默无响应，本质是目标 runid 并未存在于当前哨兵的 known-sentinel 列表中——但它可能藏在别的地方。

• SENTINEL MASTER <master-name></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 可能让新哨兵反复尝试握手、拉取配置，拖慢整个集群的故障检测收敛速度。动手前务必确认目标哨兵确实永久离线，而不是临时失联。