滚动升级的顺序
集群滚动升级按「从节点、主从角色切换、原主节点」三段推进：先把从库升到新版本，再用故障转移把主库角色交给已经升级的从库，最后升级原主库并让它作为新主库的从节点回到集群。这样每一刻集群里都有升级完成的节点在承担写入门面，服务不中断，出现问题时也能立刻停下不再推进。
基本信息
| 推荐顺序 | 先升从节点，再做主从切换，最后升原主节点 |
|---|---|
| 切换命令 | 针对指定副本的故障转移命令，或集群工具的转移子命令 |
| 推进粒度 | 每个分片一组，逐组滚动而不是全集群同时 |
| 验证手段 | 集群检查命令与业务冒烟 |
| 观察重点 | 重定向次数与命令延迟的变化 |
典型使用场景
- 小版本升级修复缺陷，希望不影响在线写入
- 大版本升级前先在一个分片上试点，验证兼容性与性能
- 升级脚本编排时明确每一组的停机与等待时间
- 升级后需要确认节点版本一致、拓扑完整、无光杆分片
- 出现异常时快速回退到升级前的节点版本
步骤示例
步骤示例
# 第一步：升级该分片的从节点并重启
docker pull redis:<新版本> && 重启从节点实例
redis-cli -p <从节点端口> INFO server | grep redis_version # 确认新版本
# 第二步：把主库角色交给已升级的从节点
redis-cli -p <从节点端口> CLUSTER FAILOVER
redis-cli --cluster check 10.0.0.11:7000 # 确认拓扑与槽无异常
# 第三步：升级原主节点，重启后它自动以副本身份重新入群
redis-cli --cluster check 10.0.0.11:7000每步核对点
| 阶段 | 核对内容 | 异常表现 |
|---|---|---|
| 升从节点 | 新版本已生效、同步追平 | 版本没变或复制长期落后 |
| 角色切换 | 主库已改指向新节点 | 切换后仍指旧主，写入报错 |
| 升原主节点 | 重启后自动成为副本 | 以主身份回归形成双主风险 |
| 整组收尾 | 无光杆分片、状态正常 | 副本数量不足或状态异常 |
每个分片逐组滚动，观察重定向与延迟指标恢复正常后再推进下一组，把变量控制在一组之内才容易定位问题。
升级窗口内避免同时做迁移与扩容，多个变更叠加会让问题现象难以归因。