升级时的持久化账本
持久化文件是升级过程中最容易出问题的一环：升级前的快照必须能被新版本加载，升级后的数据又必须能被旧版本识别，前提是计划回滚。规范做法是升级前用 redis-check-rdb 与 redis-check-aof 把现有文件校验一遍，记录键总量与几个抽样键作为对账基准，并确认备份链路独立于本机磁盘。7.0 起 AOF 由单文件改为目录结构，旧备份脚本需要同步调整。
基本信息
| 升级前 | 校验 RDB 与 AOF、记录 DBSIZE 与抽样键、确认备份可加载 |
|---|---|
| 升级中 | 观察启动日志的加载来源是真数据还是空库 |
| 升级后 | 对账键数量与抽样键，检查新版本告警 |
| 回滚前提 | 保留旧版本能加载的快照或先做逻辑导出 |
| 结构变更 | 7.0 起 AOF 目录为 appendonlydir 多文件 |
典型使用场景
- 小版本滚动升级，风险较低但仍要确认配置项没有改名
- 跨大版本升级，持久化格式与目录结构都可能变化
- 容器化实例升级镜像标签，数据卷的挂载路径必须保持一致
- 主从一起升级前先升从库并从库加载验证，再动主库
- 上线前在演练环境用新版本加载真实备份，验证可加载性
升级核对清单
升级核对清单
redis-check-rdb /data/redis/dump.rdb # 快照完整性
redis-check-aof /data/redis/appendonlydir/appendonly.aof.manifest # 7.0+ AOF 清单
redis-cli DBSIZE # 升级前记录键总数
redis-cli --scan --pattern 'order:*' | head -5 # 记几个抽样键供对账
redis-cli INFO server | grep -E 'redis_version|uptime_in_seconds' # 升级后确认版本与启动时长阶段核对表
| 阶段 | 动作 | 目的 |
|---|---|---|
| 升级前 | 校验持久化文件、记录基线数据量 | 为回滚与对账留下依据 |
| 升级前 | 单独备份一次并异地保存 | 避免升级脚本顺带覆盖本地备份 |
| 升级中 | 观察启动日志的加载来源 | 确认数据真的被载入而非空库启动 |
| 升级后 | 抽样键与键总数对账 | 尽早发现数据缺失或加载不全 |
跨大版本升级前先读对应版本的 Release Notes 里持久化相关章节，比升级完再排错省时得多，尤其是配置项改名与默认值变化。
7.0 起 AOF 变成目录结构，备份脚本若仍按单个 appendonly.aof 抓取，拿到的文件很可能不完整，演练时必须验证备份可加载。