Redis 7.0多部分AOF基础文件与增量文件层级关系解析

在 Redis 7.0 的 Multi-part AOF 持久化机制中，base 文件绝非可选的备份文件，而是整个数据恢复链的基石。缺少 base 文件，所有 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 引用该 base，再结合 CONFIG SET aof-rewrite-incremental-fsync yes 等参数观察清理行为。

最容易被忽视的一点是：manifest 文件本身不存储数据，但一旦损坏或被篡改，整个 AOF 恢复逻辑将失去坐标系。它比任何一个 base 或 incr 都更为关键，却常被运维脚本忽略备份或权限控制。这一点值得每位 Redis 运维人员牢记。