AOF重写未达100%文件大小阈值即触发的问题咨询

核心逻辑澄清 #

Redis触发自动AOF重写的条件确实是同时满足以下两个：

• aof_current_size > auto-aof-rewrite-min-size（你的配置是64MB，显然已满足）
• aof_current_size > aof_base_size * (auto-aof-rewrite-percentage / 100)

但你可能误解了aof_base_size的定义：它是上一次成功完成AOF重写后的新AOF文件大小，而非初始的AOF文件大小。每次重写完成后，Redis会自动将aof_base_size更新为重写后新文件的大小，下一次触发阈值会基于这个新值计算。

结合你的参数分析 #

从你给出的数值计算：

• aof_base_size = 5486679840字节 ≈ 5.11GB
• 100%阈值应为：5.11GB × 2 = 10.22GB
• 当前aof_current_size ≈ 5.38GB，仅比aof_base_size增长了约5%，远未达到100%的自动触发条件。因此频繁触发必然是其他原因导致。

排查步骤 #

1. 检查Redis日志，确认重写触发原因 #

Redis日志会明确记录每次AOF重写的触发源：

• 若为手动触发，日志会显示类似：User requested AOF rewrite triggered by BGREWRITEAOF command
• 若为自动触发，日志会显示触发时的阈值判断逻辑，比如：Starting automatic rewriting of AOF on size growth

2. 确认当前生效的配置参数 #

执行以下命令检查实时生效的配置，排除动态修改的可能：

redis-cli CONFIG GET auto-aof-rewrite-percentage
redis-cli CONFIG GET auto-aof-rewrite-min-size

确保返回值和你配置的100、64mb一致。

3. 检查是否存在手动触发的脚本/任务 #

排查是否有定时任务（如crontab）、运维脚本或第三方工具在执行BGREWRITEAOF命令，这会绕过自动触发条件直接启动重写。

4. 检查Redis是否频繁重启或AOF文件修复 #

• 若Redis意外重启，加载AOF文件后会将当前AOF大小设为新的aof_base_size，如果重启频繁，会不断重置触发阈值。
• 若AOF文件出现损坏并自动修复，修复后的AOF大小会被设为aof_base_size，可能导致阈值异常降低。

5. 跟踪重写前后的aof_base_size变化 #

每次重写完成后，执行INFO Persistence查看aof_base_size的新值：

redis-cli INFO Persistence | grep aof_base_size

如果重写后aof_base_size被大幅压缩（比如从5GB降到1GB），那下一次只要AOF增长到2GB就会触发重写，形成“重写→压缩→快速增长→再重写”的循环，导致频繁触发。

内容的提问来源于stack exchange，提问作者satishkumar432