Redis监控AOF重写是否正常执行

Redis的AOF重写状态不能依赖单一指标（如aof_last_rewrite_time_sec）判断，必须综合监控info persistence中的aof_rewrite_in_progress、aof_pending_rewrite和aof_last_bgrewrite_status三个字段——仅当它们分别为0、0、ok时，才能确认重写真正成功完成；同时需结合info stats中的latest_fork_usec、memory中的RSS与used_memory差值，以及系统日志中“Background AOF rewrite”“Can't BGREWRITEAOF”和OOM killer记录，进行多维度交叉验证，否则极易将卡死、失败或静默中断误判为正常运行，给数据持久化可靠性埋下严重隐患。

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

aof_last_rewrite_time_sec 只记录上一次成功完成重写的耗时（秒），不反映当前状态。它可能很久没更新，但 aof_rewrite_in_progress 是 0，说明最近没重写；也可能值是 10，但重写卡在半路——这个字段完全不管“是否卡住”，只管“有没有启动过子进程”。别靠它判断实时健康度。

真正该盯的三个 INFO 字段

用 redis-cli info persistence 查这三项组合才能交叉验证：

• aof_rewrite_in_progress：为 1 表示子进程已 fork 并正在写新文件；为 0 不代表刚结束，可能是根本没触发，也可能是失败退出了
• aof_pending_rewrite：为 1 表示有重写请求排队（比如 bgrewriteaof 已发但被阻塞），常见于 bgsave 正在跑、或 maxmemory 不足导致 fork 失败
• aof_last_bgrewrite_status：必须是 ok 才算上次成功；若为 err，得立刻查日志——大概率是磁盘满、权限错或 OOM killer 杀了子进程

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

latest_fork_usec 在 info stats 里，单位是微秒。如果它突然飙升到几万甚至百万（比如 320000），说明 fork 花了 320ms，意味着 Redis 当前 used_memory 很大（每 1GB 内存 fork 约耗 20ms）。这时再看 info memory 里的 used_memory_rss 减 used_memory：差值若稳定在 200MB 以上，且和 latest_fork_usec 峰值时间重合，基本就是 AOF 重写缓冲区 + copy-on-write 页面在吃内存。

日志里哪些行必须 grep

别只信 INFO，直接翻 /var/log/redis/redis-server.log：

• grep "Background AOF rewrite" *.log —— 看有没有 “started” 却没对应 “completed” 记录，反复出现就是重写中断循环
• grep "Can't BGREWRITEAOF" *.log —— 明确报错原因，比如 OOM 或 no space left on device
• dmesg | tail -20 | grep -i "killed process.*redis" —— 如果重写提交后卡死超 30 秒，这里很可能有 OOM killer 的 signal 9 记录

重写不是黑盒操作，它的状态散落在 INFO 字段、日志、系统事件三处，漏看任何一块都可能误判为“运行中”，实际早已静默失败。

以上就是《Redis监控AOF重写是否正常执行》的详细内容，更多关于的资料请关注golang学习网公众号！