Redis 7.0 的 appenddirname 必须配置独立挂载点、严格权限（chown redis:redis + chmod 750）并隔离于 dir，否则易因磁盘争抢、I/O 延迟或 inode 耗尽导致 AOF 写入失败、数据丢失或服务退出。
为什么 Redis 7.0 的 appenddirname 配置不能只配路径，还得管权限和挂载点
直接把 appenddirname 指向 /data/redis/aof 不等于安全——如果这个目录在系统盘、没做磁盘隔离、或被其他进程写满，AOF 写入会失败，甚至触发 redis-server 主动退出（日志里出现 Failed to open the AOF file）。更隐蔽的问题是：若该目录挂载自 NFS 或低性能 SSD，appendfsync everysec 可能因 I/O 延迟抖动导致大量命令堆积在 aof_buf，最终触发 client-output-buffer-limit 限流或连接断开。
实操建议：
-
appenddirname必须指向独立挂载的本地 NVMe 分区（如/mnt/aof-ssd），且需chown redis:redis+chmod 750 - 用
df -i检查 inode 是否充足（AOF 多文件模式下，incr-*.aof和base.aof各占一个 inode，appendonly.aof.manifest再占一个） - 禁止将
appenddirname和dir（RDB 路径）设为同一挂载点——否则 AOF 重写期间 RDBsave并发写盘可能引发磁盘争抢
如何验证 appendonly.aof.manifest 文件是否真实参与恢复流程
很多人以为只要看到 appendonly.aof.manifest 文件存在，就代表 multi-part AOF 生效了。其实不是：manifest 是恢复时的“索引表”，但若它内容损坏或顺序错乱，Redis 启动时会静默跳过增量文件，只加载 base.aof，导致数据丢失（尤其那些只存在于 incr-*.aof 中、尚未合并进 base 的写操作）。
实操建议：
- 手动检查
manifest内容：cat /mnt/aof-ssd/appendonly.aof.manifest，确认字段version≥ 1、files数组中至少含一个base和一个incr条目，且seq递增 - 模拟故障：临时重命名某个
incr-*.aof文件，再重启 Redis，观察日志是否出现Skipping incr file ... not found in manifest—— 若没报这个，说明 manifest 未被读取，配置可能被覆盖 - 升级后首次启动必须执行
redis-cli BGREWRITEAOF，否则旧版单文件appendonly.aof仍会被加载（兼容性逻辑），manifest不生效
aof-use-rdb-preamble 设为 no 才真正启用多文件，但要注意 ACL 权限继承问题
很多团队在配置里写了 aof-use-rdb-preamble no，却仍发现生成的是混合格式（base.rdb + incr.aof 混合体），原因常是：Redis 启动时从旧配置加载了 aof-use-rdb-preamble yes，而 CONFIG SET 动态修改不生效（该参数仅在启动时读取）。更关键的是，multi-part AOF 生成的每个 incr-*.aof 文件，在写入时会继承当前 Redis 进程的 umask，但若启用了 ACL，某些用户可能无权读取新生成的 incr 文件（比如备份脚本用 redis-backup 用户运行，但该用户没被授予 read 权限到 appenddirname 目录）。
实操建议：
- 确认配置生效：启动后执行
redis-cli config get aof-use-rdb-preamble，返回值必须是no；若为yes，需检查redis.conf是否被 include 覆盖，或是否存在CONFIG REWRITE写回的旧值 - ACL 用户若需访问 AOF 文件（如做离线校验），必须显式授权：
ACL SETUSER backup-user on >mypass ~* &all，其中&all表示允许访问所有文件路径（Redis 7.0+ 支持路径级文件权限控制） - 禁止对
appenddirname目录使用chmod 777—— 这会让 ACL 的resetchannels等敏感命令暴露风险
多 AOF 目录下，redis-check-aof --fix 已失效，得换工具链
老版本用 redis-check-aof --fix appendonly.aof 修复损坏日志，但在 multi-part 模式下，这个命令只会检查单个文件，完全无视 manifest 的拓扑关系。若某个 incr-*.aof 文件末尾截断，--fix 可能强行补零，导致后续所有 incr 文件顺序错乱，恢复时直接 panic。
实操建议：
- 停机修复必须用 Redis 7.0+ 自带的
redis-aof-rewrite工具：redis-aof-rewrite --dir /mnt/aof-ssd --output-dir /mnt/aof-ssd-repair，它会按manifest重建完整链路 - 线上巡检应定期跑
redis-cli --raw aof manifest dump（Redis 7.0.12+ 新增命令），输出 JSON 结构化信息，用脚本比对seq连续性和文件mtime是否倒挂 - 备份策略要同步拷贝三类文件：
base.aof、所有incr-*.aof、appendonly.aof.manifest—— 少任何一个，恢复即不可靠
多 AOF 目录的安全收益，不在“文件变多了”，而在于故障域隔离：base.aof 损坏影响全量数据，incr-*.aof 损坏只影响最近几分钟写入，manifest 损坏则整个链路失效。这三者的权限、挂载、校验、备份，必须按不同 SLA 分开管理，而不是塞进同一个配置项里一配了之。
