理解基础文件与增量文件的层级关系_Redis 7.0 Multi-part AOF中base文件如何处理

Redis 7.0 Multi-part AOF中base文件是恢复起点且不可缺失，本质为RDB格式快照，体积小、加载快；需用redis-check-rdb校验，删除则启动报错；manifest文件调度所有base与incr依赖关系，损坏将导致恢复失败。

Redis 7.0 的 Multi-part AOF 中，base 文件不是“可选备份”，而是整个 AOF 恢复链的起点——没有它，所有 incr 文件都不可用。

base 文件本质是 RDB 快照，不是 AOF 文本日志

它默认以 RDB 格式序列化当前全量数据（如 appendonly.aof.1.base.rdb），体积小、加载快。这点和旧版 AOF rewrite 生成的纯文本大文件完全不同。

• 不能用 redis-check-aof 检查或修复 base 文件——得用 redis-check-rdb
• 它不记录命令，只记录状态；所以无法从中提取某次 SET 的时间点，但能秒级加载出完整数据集
• 若你手动删掉 base 文件，Redis 启动时会报错：Failed to open base file: No such file or directory，直接拒绝恢复

incr 文件依赖 base 文件的生效范围，不是简单按时间顺序拼接

manifest 文件（appendonly.aof.manifest）才是关键调度器：它明确声明每个 incr 文件从哪个 base 开始生效、覆盖哪些写操作时间窗口。

• 比如 appendonly.aof.1.base.rdb 对应时间戳 T1，而 incr-00000001.aof 标记为 from_base=1, start_offset=12345，说明它只承接该 base 之后的增量
• 删除中间某个 incr 文件，Redis 不会崩溃，而是跳过它，用前一个 incr 的末尾状态 + 下一个 incr 的开头继续恢复
• 但若删掉的是最后一个 incr，Redis 会认为“最新状态缺失”，可能回退到上一个完整组合（即上一个 base + 其全部有效 incr），导致丢失部分写入

base 文件只允许存在一个，且不会自动轮转

Multi-part AOF 设计上限制同一时刻仅有一个活跃 base 文件——它代表当前数据基线，其余都是围绕它的增量补丁。

• 重写触发后，新 base 生成（如 .2.base.rdb），旧 base 并不立即删除，而是等所有依赖它的 incr 都被合并或归档后，由 Redis 异步清理
• 你不能手动把 .1.base.rdb 改名为 .2.base.rdb 来“欺骗”系统——manifest 文件校验失败会导致启动失败
• 如果磁盘空间紧张，不要直接 rm 旧 base；应先确认 manifest 中已无任何 incr 引用它，再配合 CONFIG SET aof-rewrite-incremental-fsync yes 等参数观察清理行为

真正容易被忽略的点在于：manifest 文件本身不存数据，但一旦损坏或被篡改，整个 AOF 恢复逻辑就失去坐标系——它比任何一个 base 或 incr 都更关键，却最常被运维脚本忽略备份或权限控制。