Redis runs an append-only-file (AOF) rewrite in a forked child process, the same way a background RDB snapshot (BGSAVE) does. Setting aside the generic cost of fork() and copy-on-write, what is different about an AOF-rewrite child in production, and which Redis INFO fields and LATENCY monitor events would you watch to observe one?

## Scope: what is *not* the subject here Every `fork()` in Redis costs a synchronous page-table copy that stalls command execution, and every forked child creates a copy-on-write window during which pages the parent writes get physically duplicated. That mechanism is generic to background persistence and is covered by the RDB fork / copy-on-write and `SAVE` vs `BGSAVE` material — take the derivation from there. This question is about what makes the *AOF-rewrite* child a different operational animal, and how you read its state off a running server. ## Four rewrite-specific effects a snapshot fork does not have **1. The child lives much longer, so the copy-on-write window is wider.** A `BGSAVE` child writes one compact binary RDB and exits. An AOF-rewrite child writes a full base file and, on older configurations that serialize the base as plain commands rather than an RDB preamble, that output is several times bulkier and slower to produce. Longer child life means more parent writes land inside the window, so peak copy-on-write memory for a rewrite is normally *higher* than for a snapshot of the same dataset. Redis reports both separately: `aof_last_cow_size` for the last rewrite, `rdb_last_cow_size` for the last snapshot. Compare them; if the AOF number is several times the RDB number, that is the wider window showing up, not a different mechanism. **2. The parent is writing to the same device the whole time.** During a `BGSAVE` with AOF disabled, only the child touches the disk. During a rewrite, the parent keeps appending live writes (in Redis 7.0+ to an incremental file alongside the new base; the multi-part AOF layout is its own topic) while the child streams the base out. Two writers, one device. The signature is a latency profile that is *elevated for the whole rewrite duration* rather than one spike at the start — and that duration is directly visible as `aof_current_rewrite_time_sec` while it runs and `aof_last_rewrite_time_sec` afterwards. **3. `no-appendfsync-on-rewrite yes` silently widens the durability window.** With this set, the parent stops issuing `fsync` on the AOF for as long as *any* persistence child is running. With `appendfsync everysec` you believe your worst-case loss is one second; during a rewrite it is however long the rewrite takes — minutes on a large instance. Nothing logs this and no INFO field says "fsyncs suspended"; the only way to know is to read `CONFIG GET no-appendfsync-on-rewrite` and multiply by `aof_last_rewrite_time_sec`. It is a real latency-for-durability trade, but it must be a stated one. **4. A rewrite requested while another child runs is scheduled, not started.** `BGREWRITEAOF` while an AOF rewrite is already in progress returns an error. While a *different* persistence child is active — an RDB save, a replica full-sync fork, a module fork — or inside `MULTI`, Redis replies `Background append only file rewriting scheduled`, sets `aof_rewrite_scheduled:1`, and starts the rewrite when the other child exits. Automatic size-based triggers are deferred the same way. So "I ran BGREWRITEAOF and nothing happened" is usually `aof_rewrite_scheduled:1` plus something that keeps occupying the fork slot; if that something recurs constantly (frequent `save` points, repeated replica resyncs), the AOF grows unbounded while the rewrite never gets a turn. ## The fields, and what each one actually tells you - `INFO stats` → `latest_fork_usec`: duration of the *fork syscall only*, in microseconds. This is the instantaneous full-server stall, not the rewrite duration. `total_forks` tells you how often you pay it. - `aof_rewrite_in_progress`: 1 while a child is running. - `aof_rewrite_scheduled`: 1 when a rewrite is queued behind another child. Stuck at 1 = starvation. - `aof_current_rewrite_time_sec` / `aof_last_rewrite_time_sec`: the child's lifetime — the width of the copy-on-write and contention window. - `aof_last_bgrewrite_status`: `ok` or `err`. `err` means the AOF is still growing; Redis backs off before retrying, and `aof_rewrites_consecutive_failures` counts the streak. - `aof_last_cow_size` (and `rdb_last_cow_size` for comparison), plus the live Redis 7 progress fields `current_cow_size`, `current_cow_peak`, `current_fork_perc`. - `aof_base_size` vs `aof_current_size`: the growth ratio the auto-trigger reasons about. - `aof_rewrite_buffer_length` existed before 7.0 as the parent-side diff buffer; multi-part AOF removed it, so do not look for it on 7.x. ## LATENCY monitor Set `latency-monitor-threshold` to a few milliseconds and Redis records named latency events. `LATENCY LATEST` returns each event with its last and max value; the `fork` event isolates the stall so you can prove or disprove that the fork caused a spike, and `LATENCY HISTORY fork` gives the series. The AOF write-path events matter just as much: `aof-write-active-child` fires when a parent AOF write blocked *while a child was running* — direct evidence of rewrite-induced disk contention rather than fork cost — alongside `aof-write-pending-fsync`, `aof-fsync-always` and `aof-rename`. ## Reading it as a routine A single spike whose width matches `latest_fork_usec` at the moment `aof_rewrite_in_progress` flips to 1 is the fork. Degradation spanning `aof_current_rewrite_time_sec` with `aof-write-active-child` events is contention. Rising `current_cow_size` through the rewrite is copy-on-write. `aof_rewrite_scheduled:1` with a growing `aof_current_size` is starvation. `aof_last_bgrewrite_status:err` is a rewrite that never happened at all.