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 行并重启哨兵，新 IP 不会被真正采纳。哨兵会继续用旧地址探测，直到超时失败，期间从节点可能反复重配、客户端持续连接旧地址失败。

正确做法是在任一哨兵上执行：

SENTINEL RESET mymaster

执行后哨兵会清空本地缓存的主节点状态，并在几秒内发起新一轮探测。此时必须确保：

1. 新主节点已启动，绑定新 IP（如 192.168.100.50），且未启用 protected-mode yes
2. 新主能响应 PING 和 INFO replication，返回 role:master 和合法 run_id
3. 所有哨兵都已完成重发现——可用 SENTINEL MASTER mymaster 查看 ip、port、flags 是否已更新为 master

客户端不能仅靠 __sentinel__:hello 频道无条件切换

订阅 __sentinel__:hello 是轻量获取变更的方式，但消息本身不带校验，多个哨兵广播存在微小时间差。直接用第 4–5 字段（IP+port）立即切断旧连接，容易连到尚未复制就绪的新主，触发 READONLY 错误或写入被拒绝。

安全做法是：

1. 收到新 IP 后，先建立新连接，执行 ROLE 命令确认返回 ["master", ]
2. 保留旧连接 5–10 秒，同时并发探测新地址是否可写
3. 若使用连接池（如 JedisPool 或 redis-py ConnectionPool），需主动调用 close() 或标记旧连接失效；否则池中残留连接仍会发请求到旧 IP

手动切换主节点前必须停掉哨兵监控

如果因主节点彻底不可恢复而需人工指定新主（比如原主宕机无法拉起），不能直接在从节点上执行 slaveof no one 后就完事。哨兵仍在运行时会检测到该节点“非预期晋升”，自动把它降级回从节点，甚至反复重配其他从节点。

必须先临时停用哨兵对主节点的监控：

1. 在所有哨兵节点上执行 SENTINEL REMOVE mymaster（或注释掉 sentinel monitor 行并 SENTINEL RESET）
2. 再登录目标新主节点，执行 slaveof no one 和 CONFIG SET slave-read-only no
3. 最后逐个让其余从节点执行 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 紧急修复了该高危漏洞，并稳定了哨兵状态同步逻辑。生产环境若尚未升级，更换主节点操作务必避开流量高峰，并准备回滚预案——因为问题常表现为“看起来切换成功，但部分从节点始终无法同步”这类难定位现象。