如何在Redis 7.0中处理Multi-Part AOF与主从复制冲突-Redis-PHP中文网

redis 7.0 multi-part aof主从数据丢失的根源是manifest文件缺失、appenddirname配置错误或aof-use-rdb-preamble设为yes导致降级混合模式，三者任一出错均会使从库跳过incr文件、仅加载base而静默丢弃断连期间全部写入。

如何在redis 7.0中处理multi-part aof与主从复制冲突

Redis 7.0 中 Multi-Part AOF 和主从复制本身不冲突，真正出问题的是 manifest 文件缺失、appenddirname 配置错误或混合模式残留——这些会导致从节点启动时跳过增量文件，数据静默丢失。

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”

这个开关决定 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 必须显式设置且与 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 文件写入位置混乱，哨兵无法正确校验从库状态

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 恢复流程