Redis怎么监控当前AOF重写操作是否正常执行_观察INFO持久化中的aof_last_rewrite_time

Redis怎么监控当前AOF重写操作是否正常执行

在维护Redis时，AOF重写是个关键的后台操作。但怎么判断它到底是在顺利进行，还是已经悄悄卡住了？很多人习惯性地去看aof_last_rewrite_time_sec这个字段，这其实是个误区。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

这张图展示的正是INFO命令中持久化相关的信息，但光看一个字段可不够。

怎么确认 AOF 重写是否真完成了

先说结论：aof_last_rewrite_time_sec这个字段，它只记录上一次成功完成重写的耗时，单位是秒。它根本不反映当前状态。这意味着什么？

一种情况是，这个值可能很久没更新了，但aof_rewrite_in_progress显示为0，这只说明最近压根没触发过重写。另一种更棘手的情况是，这个值显示是10秒，看起来很快，但重写进程可能早就卡在半路了——这个字段完全不管“是否卡住”，它只管“有没有启动过子进程”。所以，千万别单靠它来判断实时健康度。

真正该盯的三个 INFO 字段

那正确的姿势是什么？你需要用redis-cli info persistence命令，然后重点关注下面这三项的组合，进行交叉验证：

• aof_rewrite_in_progress：这个值为1，表示子进程已经fork出来，并且正在写入新的AOF文件。但如果它为0，也别高兴太早，这不代表刚成功结束，也可能是根本没触发，甚至是失败退出了。
• aof_pending_rewrite：这个值为1，意味着有重写请求在排队。比如你手动发了bgrewriteaof命令，但它被阻塞了。这种情况常见于另一个bgsa ve正在运行，或者服务器内存不足（maxmemory）导致fork失败。
• aof_last_bgrewrite_status：这个字段必须是ok，才表示上一次重写是成功的。如果显示为err，那就得立刻去查日志了——大概率是磁盘满了、文件权限错误，或者子进程被系统的OOM killer给干掉了。

简单来说，必须aof_rewrite_in_progress和aof_pending_rewrite都为0，并且aof_last_bgrewrite_status为ok，才能断定AOF重写是真正成功完成了。仅凭aof_last_rewrite_time_sec或任何一个单一字段，都容易导致误判。

重写卡住时，latest_fork_usec 和 RSS 差值怎么读

如果怀疑重写卡住了，还有两个指标能提供重要线索。它们藏在其他INFO段落里。

首先看info stats里的latest_fork_usec，单位是微秒。如果这个值突然飙升到几万甚至上百万（比如320000），那就意味着fork操作花了320毫秒。这通常说明Redis当前的used_memory很大，经验上，每fork大约1GB的内存，会消耗20毫秒左右。

接着，再看info memory里的used_memory_rss减去used_memory的差值。这个差值如果稳定在200MB以上，并且其峰值时间与latest_fork_usec的飙升时间能对上，那基本就实锤了——AOF重写缓冲区加上写时复制（Copy-on-Write）产生的内存页面，正在持续消耗额外的物理内存。

日志里哪些行必须 grep

当然，最直接的证据永远在日志里。别只迷信INFO命令的输出，直接去翻/var/log/redis/redis-server.log（路径可能因部署而异）。下面这几条grep命令是必查项：

• grep "Background AOF rewrite" *.log —— 重点看有没有“started”记录却没有对应的“completed”记录。如果“started”反复出现，那很可能陷入了重写中断又重启的循环。
• grep "Can't BGREWRITEAOF" *.log —— 这行日志会明确报错原因，比如OOM（内存不足）或者no space left on device（磁盘空间不足）。
• dmesg | tail -20 | grep -i "killed process.*redis" —— 如果重写提交后进程卡死超过30秒，这里很可能会留下OOM killer发送signal 9终止进程的记录。

说到底，AOF重写不是一个黑盒操作。它的完整状态散落在INFO字段、Redis日志和系统事件这三处。监控时漏看任何一块，都可能让你误以为它还在“运行中”，而实际上它早已静默失败。把这些点都串起来看，才能做到心中有数。