Redis AOF 重写期间磁盘空间不足怎么提前发现

Redis AOF 重写期间突然报磁盘不足，通常不是因为“旧 AOF 文件太大”这么简单。重写会生成新的 base AOF，同时继续接收写入并保存增量内容；切换完成前，旧文件、生成中的新文件和持续增长的增量文件可能同时存在。提前发现的关键，是把 INFO persistence 的状态、AOF 目录实际占用和文件系统可用空间放在同一张容量表里。

先理解 AOF 重写为什么需要额外磁盘空间

AOF 会记录改变数据集的写操作，重写的目标是用更短的命令集合重建当前数据。Redis 官方文档说明，重写期间父进程继续接收写入，子进程生成新的文件；Redis 7 以后，多部分 AOF 由 base 文件、增量文件和 manifest 共同描述。

因此，重写前至少要回答三个问题：当前 AOF 目录占了多少空间？最近一次重写生成的临时文件峰值是多少？在这段时间里，业务每分钟还会写入多少数据？只拿当前 AOF 大小乘一个固定倍数，容易在写入高峰或备份并行时失真。

用 INFO persistence 观察重写状态

先在业务低峰和高峰各采集一次持久化信息，建立自己的基线。下面的命令只读取状态，不会触发重写：

# 只查看 Redis 持久化相关字段，便于接入监控采集
redis-cli INFO persistence | awk -F: '/^(aof_|rdb_)/ {print}'

# 手动关注重写是否进行、是否排队、上次结果是否成功
redis-cli INFO persistence | grep -E 'aof_(current_size|base_size|rewrite_in_progress|pending_rewrite|last_bgrewrite_status)'

重点字段可以这样读：

aof_last_cow_size 也值得记录，但它描述的是上次重写期间的写时复制内存，不是磁盘临时文件大小。它可以帮助判断 fork 压力，不能直接拿来当磁盘预算。

把 AOF 目录占用和文件系统余量接起来

Redis 文档建议用 INFO persistence 检查重写状态；容量告警还必须落到 AOF 目录所在的文件系统。Redis 7 以后，AOF 文件通常位于 appenddirname 指定的目录，实际路径以实例配置为准。可以把下面的路径替换成真实目录：

# 统计多部分 AOF 目录的实际占用，单位为 KiB
du -sk /var/lib/redis/appendonlydir

# 查看同一文件系统的可用空间，避免只看整个主机的总剩余空间
df -Pk /var/lib/redis | awk 'NR==2 {print "available_kb=" $4, "used_percent=" $5}'

容量预算建议使用历史观测值，而不是写死一个“剩余 20% 就安全”的数字。可把每次重写期间目录占用的最大值记为 rewrite_peak，再加上监控窗口内的写入增长、备份副本和运维缓冲；当文件系统可用空间低于这组预算时，先扩容或迁移目录，再允许下一次重写。

设置告警、处理失败并保留恢复余地

生产上可以把信号拆成三档：预警是可用空间低于历史重写预算；进行中是 aof_rewrite_in_progress=1 且余量继续下降；失败是 aof_last_bgrewrite_status 不为成功或日志出现写入失败。进行中不要反复手动执行 BGREWRITEAOF，失败后也不要只靠重试掩盖根因。

如果磁盘在写入 AOF 时已经满，尾部可能出现截断。Redis 文档说明，较新的 Redis 默认可以丢弃最后一个不完整命令继续加载，但这不等于可以忽略数据损失；处理前应先保留原文件副本，再按版本和运维预案检查。真正稳妥的顺序是：停止继续制造磁盘压力，保存日志和 AOF 文件状态，补足空间，确认重写状态恢复，再安排一次可观察的重写。

相关问题

只看 aof_current_size 能判断磁盘够不够吗？

不能。它是当前 AOF 规模，重写期间还要考虑新 base、增量写入、临时 manifest 和同目录其他文件，最好叠加历史峰值与增长速率。

aof_rewrite_in_progress 为 0 就代表没有风险吗？

不代表。还要看是否有 aof_pending_rewrite、上次重写结果以及文件系统余量；排队重写可能在稍后启动。

appendfsync everysec 能解决磁盘不足吗？

不能。appendfsync 影响持久化同步频率和数据丢失窗口，不会消除 AOF 文件增长或重写期间的临时空间需求。

重写失败后应该马上再次 BGREWRITEAOF 吗？

不应盲目重试。先确认目录和文件系统余量、上次错误状态以及是否仍有 RDB 操作，再修复容量或并发压力。