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