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