redis 7.0 multi-part aof通过拆分为.base.rdb和.incr.aof等多文件实现重写优化,内存占用稳定在几十mb,避免fork全量快照与aof_rewrite_buf缓冲区暴涨问题。

Redis 7.0 的 Multi-part AOF 会让传统单文件备份脚本直接失效——它不再只生成一个 appendonly.aof,而是产生多个带编号和后缀的文件(如 appendonly.aof.1.base.rdb、appendonly.aof.2.incr.aof),漏拷任意一个都可能导致恢复失败。
如何识别当前 Redis 正在运行 Multi-part AOF
别猜,直接查。两个动作必须都做:
- 执行
CONFIG GET aof-use-rdb-preamble,确认返回值是no(若为yes,Multi-part 会被强制禁用) - 进
dir配置目录(比如/data/redis7002/data),用ls appendonly.aof.*看是否有带.base.rdb或.incr.aof的文件
只要满足以上两点,你就得按多文件逻辑处理备份,否则冷备只是“看起来有”。
备份脚本必须覆盖的文件类型和命名规律
Multi-part AOF 的文件不是随意命名的,而是有明确规则:
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis,支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 基础快照文件:形如
appendonly.aof.<num>.base.rdb</num>(例如appendonly.aof.1.base.rdb) - 增量日志文件:形如
appendonly.aof.<num>.incr.aof</num>(例如appendonly.aof.2.incr.aof、appendonly.aof.3.incr.aof) - 可能还存在
.history后缀的归档文件(如appendonly.aof.1.base.rdb.history),它们是重写过程中被替换下来的旧段,也应纳入备份范围(尤其当你要支持任意时间点恢复时)
注意:<num></num> 是递增整数,但不保证连续;不能只备份最新编号,必须全量匹配通配符。
备份脚本改写要点:避免原子性破坏与顺序错乱
Multi-part AOF 恢复依赖文件间的严格顺序和完整性,备份时稍有疏忽就会导致启动失败(报错类似 Failed to load base file: No such file or directory)。关键实操建议:
- 不要用
cp -f单独拷每个文件——改为用tar -cf打包整个匹配集,例如:tar -cf /redis_bak/backup_$(date +%y%m%d_%H%M%S).tar appendonly.aof.*.base.rdb appendonly.aof.*.incr.aof appendonly.aof.*.history - 备份前加锁:执行
redis-cli BGREWRITEAOF可能触发段切换,建议先redis-cli CONFIG SET aof-rewrite-incremental-fsync no(临时关闭增量 fsync 减少干扰),再redis-cli SAVE触发一次 RDB 落盘作为锚点,最后再打包 AOF 段 - 压缩后务必校验:用
tar -tf列出内容,确认所有.base.rdb和对应.incr.aof都在其中;再用sha256sum记录包哈希,防止传输损坏
远程同步与清理策略需同步升级
老脚本常把 appendonly.aof 当作唯一目标,直接 scp 单文件。现在必须:
- 改用
rsync --include='*/' --include='appendonly.aof.*' --exclude='*' -avz同步整个目录结构,保留文件关系 - 清理过期备份时,不能只删
*.aof.tar.gz,还要检查是否残留孤立的.base.rdb或.incr.aof文件(它们没被 tar 包含,但可能被误留) - 若使用定时任务,
find /redis_bak -name "backup_*.tar" -mtime +90 -delete这类命令仍可用,但要额外加一行:find /redis_bak -name "appendonly.aof.*" -mtime +90 -delete
最易被忽略的是:Multi-part AOF 的「冷备有效性」不取决于文件数量,而取决于 base 文件与其后续所有 incr 文件是否版本对齐、编号连续、无缺失——哪怕只少一个 .incr.aof,Redis 启动时就拒绝加载。










