快照为什么挑版本
RDB 文件头会记录生成它的格式版本号，加载时做方向性兼容检查：低版本生成的快照可以被高版本加载，高版本生成的快照会被低版本拒绝，启动日志会明确给出格式版本不支持的报错。所以升级路径通常畅通，降级却必须先有一份旧版本能认的快照。把这点搞清楚，回滚方案才有意义。
基本信息
| 兼容方向 | 低版本生成 → 高版本实例：可加载 |
|---|---|
| 反向 | 高版本生成 → 低版本实例：拒绝加载并报错 |
| 查看方式 | redis-check-rdb 输出中的版本行 |
| 相关查询 | INFO server 的 redis_version 字段 |
| 跨版本替代 | DUMP/RESTORE 逻辑迁移或业务双写 |
典型使用场景
- 大版本升级前评估回滚路径，确认旧版本能加载哪一份快照
- 主从升级顺序编排：先升从库再升主库，确保复制方向由低到高
- 用 redis-check-rdb 核对一份备份到底来自哪个版本，避免用错文件
- 跨版本迁移数据到新集群时先验证加载结果再切换流量
- 故障回滚时快照用不了，需要立刻判断能否临时用逻辑导出替代
版本核对
版本核对
redis-check-rdb /data/redis/dump.rdb | head -20 # 输出含格式版本与键数量
redis-cli INFO server | grep redis_version # 当前实例版本
grep -i 'rdb' /var/log/redis/redis.log | tail -5 # 加载失败时的原始报错
redis-check-rdb dump.rdb && redis-server --version # 先校验文件再决定升级兼容方向速查
| 组合 | 结果 | 说明 |
|---|---|---|
| 旧快照 + 新实例 | 可加载 | 向后兼容，正常升级路径 |
| 新快照 + 旧实例 | 拒绝加载 | 报格式版本不支持，回滚立刻失败 |
| 高版本 AOF + 低版本实例 | 通常不接受 | 命令与格式都可能超出旧版本能力 |
| 跨大版本迁移 | 建议逻辑迁移 | DUMP/RESTORE 或业务双写更可控 |
RDB 格式版本号与 Redis 版本号不是一一对应，多个小版本可能共用同一个格式版本，判断时以 redis-check-rdb 的实际输出为准。
主从复制也通过 RDB 传输完成首次全量同步，跨大版本混跑时从库可能拒绝加载主库传来的快照，表现为复制反复中断。