Redis AOF 重写期间磁盘空间为什么会突然变大

Redis 执行 AOF 重写时，磁盘占用突然变大，通常不是 Redis 数据在瞬间翻倍，而是新旧两代持久化文件在切换前同时存在。Redis 7 的多段 AOF 会保留旧的 base 和增量文件，子进程生成新的 base，父进程继续把写入放进新的增量文件；等新文件和临时 manifest 准备好后才原子切换并清理旧文件。因此容量规划要看“重写完成前的峰值”，不能只看平时的 AOF 大小。

重写时到底多出了哪些文件

旧版 Redis 的模型比较直观：旧 AOF 继续保证可恢复，子进程把压缩后的新 AOF 写到临时文件，重写期间的写入还会形成额外缓冲。Redis 7 起，AOF 拆成 base 文件、incremental 文件和 manifest。重写开始后，旧文件仍是安全底座，子进程写新的 base，父进程打开新的增量文件接收实时写入；临时 manifest 完成原子替换前，旧代和新代都不能删除。

可以把峰值粗略理解为：旧代文件 + 新 base + 重写期间新增写入 + 临时文件与文件系统开销。新 base 不一定等于当前目录的全部文件大小，但在数据量大、写入持续、重写时间长时，给新旧两代留出接近两份数据集的空间更稳妥。

先用三个观察点确认是不是 AOF 重写

不要看到磁盘上涨就直接删除文件。先确认重写状态、AOF 目录大小和整个挂载点余量，三者要放在同一个时间窗口观察：

# 查看重写状态、最近一次结果和 AOF 文件计数
redis-cli INFO persistence | egrep 'aof_rewrite_in_progress|aof_rewrite_scheduled|aof_last_bgrewrite_status|aof_current_size|aof_base_size|aof_rewrites'

# 查看 AOF 目录与 Redis 数据目录的真实占用
du -sh /var/lib/redis/appendonlydir /var/lib/redis

# 查看挂载点余量；不要只根据 du 判断是否还能写入
df -h /var/lib/redis

aof_rewrite_in_progress:1 说明子进程仍在生成新 base；aof_rewrite_scheduled:1 只表示任务已排队，不能把它当成已经释放空间。df 比 du 更接近 Redis 能否继续创建文件的真实答案，因为同一挂载点还可能有日志、备份或已删除但仍被进程打开的文件。

生产环境如何留出重写峰值

容量检查要以重写期间的最大占用为准。对 Redis 7 多段 AOF，至少把当前 AOF 目录大小、新 base 生成空间和重写期间增量写入放进预算，同时留出操作系统与日志余量。高写入实例不要在备份、日志轮转和重写任务同时发生时共享一个逼仄的盘。

如果要复制 AOF 作为备份，先确认没有重写；官方文档建议检查 aof_rewrite_in_progress 为 0，再复制 appenddirname 下的文件。备份期间临时关闭自动重写也必须在完成后恢复，并持久化配置，避免重启后仍处于错误状态。

# 仅在已经有备份方案和变更窗口时使用；记录原值，完成后恢复
redis-cli CONFIG GET auto-aof-rewrite-percentage
redis-cli INFO persistence | grep aof_rewrite_in_progress

# 重写完成且确认空间充足后，再按原值恢复自动重写
redis-cli CONFIG SET auto-aof-rewrite-percentage 100

常见问题

重写完成后空间为什么没有立刻回到原值？

先确认 manifest 已切换且重写状态归零，再看文件清理是否完成；日志、备份和其他进程打开的文件也可能继续占用空间。

能不能手动删除旧的 AOF 文件？

不能把目录里的旧文件当普通临时文件删除。Redis 仍可能依赖它们完成恢复或切换，应该通过 Redis 自己的重写和清理机制回收。

磁盘只剩很少空间还要不要执行 BGREWRITEAOF？

不建议。先估算新旧两代文件和写入增量的峰值，扩容或更换窗口后再执行；否则失败重试可能进一步消耗空间。

把 AOF 重写看成一次“新旧持久化代际并存”的切换，就能解释大多数磁盘峰值。日常监控同时采集 aof_current_size、重写状态、AOF 目录大小和挂载点余量，告警才会早于一次失败的重写。