更换主节点IP必须执行SENTINEL RESET，仅改sentinel.conf并重启无效；需确保新主启动、绑定新IP、禁用protected-mode、响应PING和INFO；客户端应先验证新主ROLE再切换；人工切换前须先SENTINEL REMOVE；建议升级至Redis 8.2.3修复CVE-2025-62507。
更换主节点 IP 时必须执行 SENTINEL RESET
只改 sentinel.conf 里的 sentinel monitor 行并重启哨兵，新 IP 不会被真正采纳。哨兵会继续用旧地址探测，直到超时失败，期间从节点可能反复重配、客户端持续连接旧地址失败。
正确做法是在任一哨兵上执行：
SENTINEL RESET mymaster
执行后哨兵会清空本地缓存的主节点状态，并在几秒内发起新一轮探测。此时必须确保：
- 新主节点已启动，绑定新 IP（如
192.168.100.50），且未启用protected-mode yes - 新主能响应
PING和INFO replication，返回role:master和合法run_id - 所有哨兵都已完成重发现——可用
SENTINEL MASTER mymaster查看ip、port、flags是否已更新为master
客户端不能仅靠 __sentinel__:hello 频道无条件切换
订阅 __sentinel__:hello 是轻量获取变更的方式，但消息本身不带校验，多个哨兵广播存在微小时间差。直接用第 4–5 字段（IP+port）立即切断旧连接，容易连到尚未复制就绪的新主，触发 READONLY 错误或写入被拒绝。
安全做法是：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 收到新 IP 后，先建立新连接，执行
ROLE命令确认返回["master", ] - 保留旧连接 5–10 秒，同时并发探测新地址是否可写
- 若使用连接池（如
JedisPool或redis-py ConnectionPool），需主动调用close()或标记旧连接失效；否则池中残留连接仍会发请求到旧 IP
手动切换主节点前必须停掉哨兵监控
如果因主节点彻底不可恢复而需人工指定新主（比如原主宕机无法拉起），不能直接在从节点上执行 slaveof no one 后就完事。哨兵仍在运行时会检测到该节点“非预期晋升”，自动把它降级回从节点，甚至反复重配其他从节点。
必须先临时停用哨兵对主节点的监控：
- 在所有哨兵节点上执行
SENTINEL REMOVE mymaster（或注释掉sentinel monitor行并SENTINEL RESET） - 再登录目标新主节点，执行
slaveof no one和CONFIG SET slave-read-only no - 最后逐个让其余从节点执行
replicaof 192.168.1.12 6379（注意 Redis 5+ 已弃用slaveof，统一用replicaof）
升级到 Redis 8.2.3 可规避 CVE-2025-62507 导致的切换异常
旧版本（尤其是 7.x 及更早）在哨兵故障转移过程中，若遇到特定网络抖动或 HyperLogLog 数据结构异常，可能触发进程崩溃或状态卡死，导致 SENTINEL MASTER 返回信息不一致、ROLE 命令超时等隐性故障。
Redis 8.2.3 紧急修复了该高危漏洞，并稳定了哨兵状态同步逻辑。生产环境若尚未升级，更换主节点操作务必避开流量高峰，并准备回滚预案——因为问题常表现为“看起来切换成功，但部分从节点始终无法同步”这类难定位现象。
