Redis Error Guide: 'Background append only file rewriting already in progress' — Fix Overlapping BGREWRITEAOF
Fix Background append only file rewriting already in progress in Redis: diagnose concurrent BGREWRITEAOF, auto-rewrite races, and slow AOF forks.
- #redis
- #troubleshooting
- #errors
- #persistence
Stuck on this Redis error? Get the free incident triage checklist
A one-page PDF — the exact steps to isolate, fix, and verify a production error like this one. No spam, unsubscribe anytime.
Overview
Redis returns Background append only file rewriting already in progress when you issue BGREWRITEAOF while an AOF rewrite child process is already running. AOF rewrite compacts the append-only file by forking a child that writes a fresh, minimal AOF; Redis allows only one such rewrite at a time.
The literal error clients receive:
(error) ERR Background append only file rewriting already in progress
Like the RDB save guard, this is protective — a second concurrent rewrite is not allowed. It appears when a manual BGREWRITEAOF collides with the automatic rewrite Redis triggers via auto-aof-rewrite-percentage, or when a rewrite is slow because the AOF is large or the disk is busy.
Symptoms
BGREWRITEAOFreturns the error;INFO persistenceshows a rewrite in flight.- Coincides with automatic rewrites or a large AOF and slow disk.
- May queue: Redis can schedule a rewrite to start after the current one finishes.
redis-cli BGREWRITEAOF
(error) ERR Background append only file rewriting already in progress
Common Root Causes
1. A rewrite is genuinely still running
The previous manual or automatic rewrite has not completed.
redis-cli INFO persistence | grep -E 'aof_rewrite_in_progress|aof_rewrite_scheduled'
aof_rewrite_in_progress:1
aof_rewrite_scheduled:0
2. Manual call races the automatic trigger
auto-aof-rewrite-percentage fired a rewrite at the same moment your script called BGREWRITEAOF.
redis-cli CONFIG GET auto-aof-rewrite-percentage
redis-cli CONFIG GET auto-aof-rewrite-min-size
3. The rewrite is slow
A large dataset, slow disk, or I/O contention makes each rewrite take long enough to collide with the next request.
redis-cli INFO persistence | grep -E 'aof_last_rewrite_time_sec|aof_current_size'
4. RDB save is also forking
An in-progress BGSAVE holds the single child slot; Redis serializes child processes.
redis-cli INFO persistence | grep rdb_bgsave_in_progress
How to diagnose
Step 1: Confirm a rewrite is in progress
redis-cli INFO persistence | grep -E 'aof_rewrite_in_progress|aof_last_bgrewrite_status'
aof_rewrite_in_progress:1 means the guard is correct — wait.
Step 2: Check how long rewrites take
redis-cli INFO persistence | grep -E 'aof_last_rewrite_time_sec|aof_current_size|aof_base_size'
A large aof_current_size versus aof_base_size explains frequent auto-rewrites.
Step 3: Look for overlapping triggers in the log
sudo journalctl -u redis-server --no-pager | grep -iE 'AOF rewrite|Background AOF|rewriting' | tail
Step 4: Check whether an RDB save is competing
redis-cli INFO persistence | grep -E 'rdb_bgsave_in_progress|aof_rewrite_scheduled'
aof_rewrite_scheduled:1 means Redis will start the rewrite automatically once the current child finishes.
Fixes
Wait for the current rewrite, then retry
while [ "$(redis-cli INFO persistence | tr -d '\r' | awk -F: '/aof_rewrite_in_progress/{print $2}')" = "1" ]; do
sleep 1
done
redis-cli BGREWRITEAOF
Rely on automatic rewrites instead of manual ones
Tune the thresholds and let Redis manage timing, avoiding manual races:
redis-cli CONFIG SET auto-aof-rewrite-percentage 100
redis-cli CONFIG SET auto-aof-rewrite-min-size 64mb
redis-cli CONFIG REWRITE
Speed up rewrites
Move the AOF directory to faster disk, ensure RAM headroom for the fork’s copy-on-write, and keep appendfsync everysec (not always) unless durability demands otherwise.
Stagger AOF and RDB schedules
Avoid forcing BGSAVE and BGREWRITEAOF at the same moment; they compete for the single child slot.
What to watch out for
aof_rewrite_scheduled:1means your request was accepted and queued, not lost — Redis will run it next. That is often the desired outcome.aof_last_bgrewrite_status:errsignals a failed rewrite (disk full, permissions) — a different problem than “already in progress”.- The rewrite fork can transiently increase memory via copy-on-write; size the host so a rewrite under write load cannot exhaust RAM.
- With
appendfsync always, rewrites and fsyncs contend harder for disk; watch latency during rewrites.
Related
- Redis Error: ‘ERR Background save already in progress’
- Redis Error: ‘Can’t save in background: fork: Cannot allocate memory’
- Redis Error: ‘Bad file format reading the append only file’ (corrupt RDB/AOF)
Paste the failing command into the free incident assistant, and browse more Redis guides.
Fixed it? Get 500 Redis & DevOps AI prompts — free
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.
Did this fix your issue?
Get 500 Battle-Tested DevOps AI Prompts — Free
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.