残留旧主节点地址会导致哨兵持续连接失效地址，产生大量+sdown/+odown日志告警，并干扰新主节点客观下线判断；必须停进程后手动删除sentinel monitor行并重启验证。

哨兵配置里残留的旧主节点地址会导致什么问题

Redis 哨兵（Sentinel）在故障转移后，如果旧主节点又重新上线，而 sentinel.conf 里仍保留着它作为 master 的配置行（比如 sentinel monitor mymaster 10.0.1.100 6379 2），哨兵会持续尝试连接这个已下线或 IP 变更的地址，产生大量日志告警：+sdown master mymaster 10.0.1.100 6379、+odown master mymaster 10.0.1.100 6379，甚至干扰新主节点的客观下线判断。

手动修改 sentinel.conf 前必须停掉对应哨兵进程

哨兵不支持热重载配置（SENTINEL RESET 或 CONFIG REWRITE 对监控配置无效），直接改文件再发 SIGHUP 不生效。必须先停止进程，再修改，再重启。

• 查进程：ps aux | grep "redis-sentinel"，确认 PID 和配置路径（如 /etc/redis/sentinel.conf）
• 停进程：kill -9 <pid></pid>（避免 graceful shutdown 拖延）
• 备份原配置：cp /etc/redis/sentinel.conf /etc/redis/sentinel.conf.bak.$(date +%s)

只删 sentinel monitor 行，别碰自动生成的 sentinel known-replica 和 sentinel known-sentinel

哨兵启动后会自动发现从节点和其它哨兵，并写入配置文件。这些 known-* 行是运行时状态快照，不是静态配置；删掉它们重启后会重新发现。但 sentinel monitor 是唯一决定“监控谁”的指令，必须精准修正：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 找到形如 sentinel monitor <name><ip><port><quorum></quorum></port></ip></name> 的行
• 确认该 <ip>:<port></port></ip> 是否已永久下线（不是临时宕机）
• 整行删除，不要只改 IP —— 哨兵不会“覆盖”，只会叠加新 monitor 行，导致重复监控
• 确保只剩一个 sentinel monitor 指向当前真实主节点（可通过 redis-cli -p 26379 SENTINEL MASTER mymaster 核对）

重启后用命令验证哨兵是否真正“忘记”旧主

重启后不能只看进程起来没，要确认旧主不再出现在哨兵视图里：

• 连哨兵端口：redis-cli -p 26379
• 查主节点当前地址：SENTINEL GET-MASTER-ADDR-BY-NAME mymaster → 应返回新主 IP
• 查所有被监控实例：SENTINEL MASTER mymaster → 输出中 ip 和 port 必须匹配新主
• 查哨兵自己记录的“已知主节点”列表：SENTINEL MONITORS → 返回结果应只有 1 条，且 name 匹配

如果 SENTINEL MASTER 里还显示旧 IP，说明配置没生效或重启错了进程；如果 SENTINEL MONITORS 返回空，说明 sentinel monitor 行被误删或写错 name。