版本升级与滚动升级是什么
Redis 升级的核心是「先读发行说明、再预发演练、最后滚动执行」。RDB 与 AOF 的持久化格式向后兼容但向前不兼容：用新版本生成的数据文件无法被旧版本读取，因此降级前必须有可用备份。滚动升级的顺序是从库到主库（或先切换主库再升级旧主），让链路在任意时刻都有可用节点与回退余地。
基本信息
| 升级方式 | 原地替换二进制 + 重启；或主从滚动升级 |
|---|---|
| 必备前置 | 完整备份（RDB 或 AOF）、旧版本二进制与配置快照 |
| 兼容性 | 持久化文件向下不兼容，降级需恢复备份 |
| Cluster | 逐节点升级，注意槽分配与复制关系保持 |
| 验证点 | 版本号、关键命令行为、客户端连接、复制状态 |
| 回滚前提 | 旧二进制 + 备份数据 + 配置三件套齐全 |
典型使用场景
- 小版本升级：修复缺陷与安全问题，风险相对可控
- 大版本升级（如 6 到 7）：先确认新特性依赖与默认值变化
- Cluster 滚动升级：逐分片逐节点替换，保持集群可用
- 云上实例版本变更前的自查与演练
- 升级后回滚演练：验证旧版本二进制与备份可恢复
升级前检查
升级前检查
# 当前版本与架构
redis-server --version
redis-cli INFO server | grep -E 'redis_version|redis_mode|os'
# 集群状态（Cluster 环境）
redis-cli --cluster check 10.0.0.1:6379
# 备份：先持久化并落地文件
redis-cli BGSAVE; redis-cli BGREWRITEAOF
redis-cli INFO persistence | grep -E 'rdb_last_bgsave_status|aof_last_bgrewrite_status'
mkdir -p /backup/redis && cp /var/lib/redis/appendonlydir/* /backup/redis/ 2>/dev/null || cp /var/lib/redis/dump.rdb /backup/redis/
# 升级后验证
redis-cli INFO server | grep redis_version
redis-cli INFO replication | grep -E 'role|master_link_status'滚动升级顺序
滚动升级顺序
# 1) 先升级一台从库，观察复制与业务读流量是否正常
# 2) 逐台升级其余从库，每次升级后确认 master_link_status 为 up
# 3) 在低峰窗口用故障转移（或哨兵/集群仲裁）把主切到已升级节点
# 4) 升级旧主，回挂为新主的从库
# 5) 全量回归：连接、过期、持久化、慢命令、客户端兼容性风险点与对策
| 风险 | 表现 | 对策 |
|---|---|---|
| 默认值变化 | 升级后行为悄悄改变（如持久化目录结构） | 逐条比对发行说明，配置显式声明 |
| 旧客户端不兼容 | 新命令或认证方式不支持，连接报错 | 升级前核对客户端库版本 |
| 持久化格式升级 | 无法降级到旧版本启动 | 升级前留可恢复备份并在预发验证 |
| Cluster 节点不一致 | 槽迁移或故障转移异常 | 逐节点升级并每步核对集群状态 |
| 配置项被移除 | 启动失败或参数被忽略 | 启动日志与 CONFIG GET 双重核对 |
跨大版本升级前先看发行说明里的破坏性变更与默认值调整，并在预发环境验证持久化文件与客户端库；演练时把「回滚」也走一遍，确认旧二进制与备份真的可用。
不要直接升级主库：一旦出现兼容问题，回滚窗口极短，而数据文件可能已被新版本改写；正确顺序是先升从库、确认稳定后再切换主库。