Redis 7.0 Multi-Part AOF主从数据丢失的根源是manifest文件缺失、appenddirname配置错误或aof-use-rdb-preamble设为yes导致降级混合模式，三者任一出错均会使从库跳过incr文件、仅加载base而静默丢弃断连期间全部写入。
Redis 7.0 中 Multi-Part AOF 和主从复制本身不冲突，真正出问题的是 manifest 文件缺失、appenddirname 配置错误或混合模式残留——这些会导致从节点启动时跳过增量文件，数据静默丢失。
manifest 文件损坏或未同步会直接导致从库丢数据
Multi-Part AOF 恢复依赖 appendonly.aof.manifest 协调 base.aof 和多个 incr-*.aof 的加载顺序。该文件不参与 AOF rewrite，但必须完整存在且内容准确。
- 手动清理旧 incr 文件（如用
redis-cli BGREWRITEAOF后删掉旧incr-*.aof）却不调用CONFIG SET appenddirname触发 manifest 重写 → manifest 仍指向已删除文件 → 从库启动时跳过后续所有 incr，只加载 base，丢失断连期间全部写入 - 备份脚本只打包
base.aof和incr-*.aof，漏掉manifest→ 从库恢复后无法识别增量链，降级为仅加载 base - 主从目录使用同一磁盘分区，运维清日志脚本误删
*manifest*→ 现象是 INFO persistence 显示 aof_enabled:1，但 aof_current_size 不涨，redis-check-aof --fix报 “no manifest found”
aof-use-rdb-preamble 配置错误会让 Multi-Part 彻底失效
这个开关决定 Redis 走哪条持久化路径：yes 回退到 6.x 混合模式（RDB 头 + AOF 尾），no 才启用纯 Multi-Part。它不是“可选优化”，而是 Multi-Part 的硬性前提。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
CONFIG GET aof-use-rdb-preamble返回yes→ 即使目录里有base.aof和incr-*.aof，实际仍走单文件逻辑，aof_rewrite_buf可能复活，内存压力和卡顿重现 - 升级 Redis 7.0 后未修改配置，沿用旧 redis.conf → 默认值是
yes，等于主动关闭 Multi-Part 核心优势 - 主库设为
no，但从库配置仍是yes→ 主从握手时复制流能建立，但从库重启后按混合模式解析 AOF，manifest 被忽略，增量命令丢失
appenddirname 未独立配置会引发文件混放与误删风险
appenddirname 必须显式设置且与 dir 分离，否则 base/incr/manifest 全堆在主数据目录下，和 dump.rdb、temp-*.rdb 混在一起。
- 未配
appenddirname→ 所有 AOF 文件写入dir目录 → 运维脚本执行find /var/lib/redis -name "temp-*" -delete时可能误删incr-00000001.aof -
appenddirname和dir指向同一路径 →CONFIG REWRITE可能覆盖关键配置项，manifest 文件权限被重置为 600（而 Redis 7.0 要求至少 644 才能读取） - 容器部署中挂载单个 volume 到
/data，但未在 conf 中区分dir和appenddirname→ 故障切换后新主库的 AOF 文件写入位置混乱，哨兵无法正确校验从库状态
FUNCTION LOAD 函数同步依赖 Multi-Part AOF 的完整性
Redis 7.0 的 FUNCTION LOAD 会把函数写入 AOF，作为数据一部分参与主从复制。但如果 Multi-Part 恢复失败（比如 manifest 错误导致 incr 文件没加载），函数定义就只存在于 base 快照里，而 base 是全量快照，不包含中间注册/删除操作。
- 主库执行
FUNCTION LOAD→FCALL→FUNCTION KILL→ 再FUNCTION LOAD新版本 → 这些操作全记录在 incr 文件中 - 若从库因 manifest 问题跳过 incr 文件 → 只加载 base 中的老函数 →
FCALL执行旧逻辑，甚至报错UNKNOWN FUNCTION（因为 base 里根本没存最新函数） - 对比
SCRIPT LOAD：它不落盘，所以不受 AOF 机制影响；但FUNCTION是持久化数据，它的生命周期完全绑定于 AOF 恢复流程
最容易被忽略的不是“要不要开 Multi-Part”，而是 manifest 是否被纳入备份策略、appenddirname 对应的磁盘是否被监控脚本清空、以及 aof-use-rdb-preamble 在主从配置中是否严格一致——三者任意一个松动，Multi-Part 就从优化变成隐患。
