应通过aof_rewrite_in_progress、aof_pending_rewrite、aof_last_bgrewrite_status三字段组合判断aof重写是否真正完成：前两者为0且后者为ok才表示成功；仅凭aof_last_rewrite_time_sec或单个字段易误判。

怎么确认 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 字段、日志、系统事件三处，漏看任何一块都可能误判为“运行中”，实际早已静默失败。