要判断aof重写是否正常，需同时检查aof_rewrite_in_progress、aof_pending_rewrite和aof_last_bgrewrite_status三项：前者为1表示正在重写，后者为1表示有排队请求，status必须为ok才代表上次成功；若aof_base_size为0则自动触发失效，需手动执行bgrewriteaof恢复；磁盘i/o卡顿（如%util≈100%、w_await>50ms）或文件系统不支持fsync（如nfs、overlayfs）是“卡住无报错”的主因，须用iostat和mount实证。
看 INFO persistence 里三个关键字段是否归零
别只盯着 aof_last_rewrite_time_sec，它只记上一次成功耗时，卡住或失败了也不更新。真正要盯的是：aof_rewrite_in_progress、aof_pending_rewrite 和 aof_last_bgrewrite_status 这三项组合：
-
aof_rewrite_in_progress为 1：子进程已 fork，正在写新 AOF；为 0 不代表成功，可能是根本没启动，也可能是子进程已崩溃退出 -
aof_pending_rewrite为 1：说明有重写请求排队等待，常见于bgsave正在跑、fork()失败（比如vm.overcommit_memory=0且内存不足）、或maxmemory触发 OOM 阻止 fork -
aof_last_bgrewrite_status必须是ok才算上次真成功；若为err，立刻查 Redis 日志，90% 以上是磁盘满、权限错、或子进程被 OOM killer 杀掉
查日志里有没有 “Could not rename” 或 “Invalid argument”
这两类错误直接暴露失败根因，但表现完全不同：
-
Could not rename the temporary AOF file：大概率磁盘空间不足，或 Redisdir目录权限不对（子进程用的是 Redis 启动用户，不是 root）；也可能旧 AOF 文件被其他进程锁定（比如误启多个实例） -
Invalid argument：不是配置问题，而是文件系统不支持fsync原子语义——NFS、FUSE、overlayfs、只读挂载、无日志的 ext2 都会触发；用mount | grep $(redis-cli config get dir | awk '{print $2}')和stat -f -c "%T" /path/to/redis/dir确认挂载类型和选项
确认 aof_base_size 是否为 0
自动触发机制会静默失效，哪怕 aof_current_size 已超 auto-aof-rewrite-min-size：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
aof_base_size = 0意味着从未成功完成过一次 AOF 重写——可能是首次启用 AOF、上次重写失败后冻结、或从节点刚加载完 RDB 还没来得及重写 - 此时
(aof_current_size - aof_base_size) / aof_base_size除零无意义，Redis 直接跳过百分比判断，自动机制形同虚设 - 手动执行
BGREWRITEAOF不受此限，可用来验证是否真能跑通；成功一次后，aof_base_size就会更新，自动机制才重新激活
检查磁盘 I/O 是否被卡死
AOF rewrite 子进程本质是顺序写大文件，I/O 卡住是最隐蔽也最常被忽略的瓶颈：
- 运行
iostat -x 1，重点看：%util是否持续接近 100%、w_await是否 >50ms、wkB/s是否远低于磁盘标称顺序写速度（SATA SSD 约 400–500 MB/s，NVMe 应达 2 GB/s+） - 别忘了主进程还在读——
rKB/s若同步飙升，说明bgsave、旧 AOF 刷盘（appendfsync everysec）、或 page cache 回写在争抢磁盘带宽 - 确认
no-appendfsync-on-rewrite yes已启用，否则 rewrite 期间还会额外触发 fsync，进一步拖慢写入
真正难排查的不是报错本身，而是“没报错却一直卡在 in_progress=1”——这时候往往不是 Redis 问题，而是磁盘写吞吐见顶、或文件系统拒绝 fsync 调用却只返回静默延迟。必须用 iostat 和 mount 实锤，不能靠猜。
