哨兵模式下升级更敏感，因依赖心跳、拓扑同步和配置共识，节点短暂失联易触发误判与故障转移；须分阶段滚动升级：先从节点、再哨兵、最后主节点，并调优down-after-milliseconds和failover-timeout等参数。
不能直接对运行中的哨兵节点或主从节点做二进制替换式升级——redis-server 或 redis-sentinel 进程重启会触发主观下线判定，极易引发误判、脑裂甚至非预期的故障转移。
为什么哨兵模式下升级比单机更敏感
哨兵集群依赖持续心跳（每秒 PING）、拓扑同步（每2秒 __sentinel__:hello 频道广播）和配置共识（quorum 投票）。任意节点在升级过程中短暂失联，可能被其他哨兵标记为 SDOWN；若多个哨兵同时升级或主节点恰好在此时抖动，就可能跨过 ODOWN 门槛，触发本不必要的 failover。
- 主节点升级：必须确保复制偏移量不丢、
runid不变（否则从节点需全量重同步） - 从节点升级：要避免在
psync过程中被哨兵误判为“同步中断” - 哨兵节点升级：最危险——它不存数据，但控制决策权；单个哨兵重启 >
down-after-milliseconds（默认5000ms），就会被其他哨兵踢出共识组
分阶段滚动升级的具体操作顺序
按影响面从小到大执行，全程保持至少 quorum 个哨兵在线且能通信，主节点始终有 ≥2 个健康从节点。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先升级所有从节点：
redis-server进程逐台停旧启新，确认INFO replication中master_link_status:up且slave_repl_offset持续追平 - 再升级哨兵节点：逐个用
kill -USR2（如果编译时启用了REPLACE支持）或更稳妥地，用新版本redis-sentinel启动临时哨兵，等其完成握手并加入集群后，再kill -TERM旧进程（依赖pidfile精准控制） - 最后升级主节点：必须选在低峰期，提前
CONFIG REWRITE确保配置兼容，然后按“先降级为从、再升为新主”两步走——即先SLAVEOF <new_slave_ip><port></port></new_slave_ip>让它变成从节点，等同步完成，再发SENTINEL failover mymaster主动触发一次受控切换，把升级后的节点推为新主
关键配置与验证要点
升级前务必检查并调优以下参数，否则默认值会在升级窗口放大风险：
-
down-after-milliseconds建议设为 10000–15000ms（而非默认5000ms），给进程重启留出缓冲时间 -
failover-timeout必须 > 单节点升级耗时（例如设为 180000），防止哨兵在升级中途就放弃等待、强行选新主 - 升级后立即验证：
SENTINEL masters确认主节点flags无odown，SENTINEL slaves mymaster查所有从节点state为online，且offset差值 - 严禁在升级过程中修改
quorum值或增删哨兵节点——这会重置投票状态，导致客观下线判定逻辑混乱
真正难的不是命令怎么写，而是判断哪一刻该停、哪一刻该切、哪一刻该等。一次升级里最易被忽略的，是哨兵之间通过 __sentinel__:hello 频道交换的“元信息”同步延迟——它不报错，但会让新哨兵短暂看不到旧哨兵的最新心跳，从而在几秒内处于“半失联”状态。这个间隙，就是故障转移最可能意外触发的窗口。
