redis 7.0 主从同步不自动使用 multi-part aof；mp-aof 是从节点本地持久化机制，仅影响自身重启恢复，主从间仍通过 psync 协议传输命令流或 rdb 快照，与 aof 文件格式无关。
Redis 7.0 主从同步是否自动使用 Multi-part AOF？
不自动。主从同步本身仍基于 PSYNC 协议和 replication buffer，与 AOF 文件格式无关；Multi-part AOF（MP-AOF）是**本地持久化机制**，只影响从节点自身重启时的数据恢复方式，不影响主从之间的传输内容或协议。
也就是说：主库发给从库的增量数据，仍是命令流（或 RDB 快照），不会因为从库启用了 MP-AOF 就改用 appendonly.aof.1.incr.aof 文件去同步——那些文件只在从库本地磁盘上存在，不参与网络复制。
- 主从之间传输的是逻辑命令（AOF mode）或二进制快照（RDB mode），由
repl-backlog和PSYNC控制 - MP-AOF 的三件套：
appendonly.aof.1.base.rdb、appendonly.aof.1.incr.aof、appendonly.aof.manifest，仅用于从节点进程崩溃后快速加载本地状态 - 若从节点配置了
aof-use-rdb-preamble yes（默认开启），它在生成 AOF 时会先写一个 RDB 基础快照，但这和主从同步中“主发 RDB 给从”是两回事
如何让从节点启用 Multi-part AOF？
必须显式开启，并确保配置项兼容。Redis 7.0 默认仍使用传统单文件 AOF，MP-AOF 是 opt-in 特性。
- 确认 Redis 版本 ≥ 7.0.0（非 RC 版）：
redis-server --version - 在
redis.conf中启用 AOF 并指定 MP-AOF 模式：appendonly yes<br>appendfilename "appendonly.aof"<br>aof-use-rdb-preamble yes<br># 关键：启用多文件模式<br>aof-rewrite-incremental-fsync yes<br># 注意：以下选项必须为 yes 才能触发 MP-AOF 生成<br>aof-load-truncated no<br>aof-use-rdb-preamble yes
-
aof-rewrite-incremental-fsync不是 MP-AOF 的开关，但它影响 rewrite 过程中子进程是否分段刷盘；真正决定是否生成多文件的是内部 rewrite 逻辑 +aof-use-rdb-preamble+ Redis 7.0+ 内核行为 - 重启从节点后，观察
appendonlydir/目录下是否出现.base.rdb+.incr.aof+.manifest三文件组合，而非单一appendonly.aof
为什么从节点启用了 MP-AOF，重启后仍加载缓慢？
常见误区：以为开了 MP-AOF 就自动加速恢复。实际效果取决于 base 文件大小、增量文件数量、以及磁盘 I/O 能力。
- 首次加载需先读取
.base.rdb（快），再顺序回放所有.incr.aof（慢，尤其是高写入场景下可能堆积多个增量段） - 如果
appendonlydir/下有大量.incr.aof.N文件（如.incr.aof.2、.incr.aof.3），说明 AOF rewrite 频繁但未合并，恢复时要逐个打开、校验、回放，开销叠加 -
.manifest文件虽小，但它是加载入口；若损坏或缺失，Redis 会 fallback 到传统 AOF 加载逻辑，甚至报错Invalid manifest file - 避免频繁 rewrite：调大
auto-aof-rewrite-percentage和auto-aof-rewrite-min-size，减少 MP-AOF 分片数量
主节点用 RDB，从节点用 MP-AOF，会有兼容问题吗？
没有。主从角色独立管理各自持久化策略，协议层完全解耦。
主节点可以配置 save ""（禁用 RDB）+ appendonly yes（单文件 AOF），而从节点配置 MP-AOF，两者互不干扰。唯一约束是：从节点必须能解析主节点发来的同步数据——这由 PSYNC 协议保证，与本地磁盘格式无关。
但要注意一个易忽略点：MP-AOF 的 .base.rdb 是标准 RDB 格式，可被任何 Redis 7.0+ 实例识别；但 .incr.aof 是 Redis 7.0 新增的二进制增量格式，无法被 6.x 或更早版本加载。所以如果你计划降级从节点版本，必须先关闭 MP-AOF 并执行一次传统 AOF rewrite。
