残留旧主节点地址会导致哨兵持续连接失效地址，产生大量+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>（避免 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>的行 - 确认该
<ip>:<port>是否已永久下线（不是临时宕机） - 整行删除，不要只改 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。
