Redis can start an append-only-file rewrite on its own. Explain how the auto-aof-rewrite-percentage and auto-aof-rewrite-min-size settings decide when that happens, and what baseline size the growth is measured against.

## The two knobs ``` auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb ``` These are the only inputs to Redis's automatic rewrite decision, and they are evaluated together in the server's periodic housekeeping cycle (`serverCron`), not on every command. ## The baseline The percentage is not measured against the dataset size, and not against a fixed number. It is measured against a remembered **baseline**: the size of the AOF immediately after the last successful rewrite. `INFO persistence` exposes it as `aof_base_size`, next to `aof_current_size`. Two details matter: - If no rewrite has occurred since the server started, the baseline is the AOF size **at startup**. So a server restarted with an already-large AOF starts from that large baseline and will not rewrite until it has grown by the configured percentage over it. - The baseline is updated only on a *successful* rewrite. A rewrite that fails (disk full, child killed) leaves the old baseline in place, and Redis will attempt again later. ## The rule A rewrite is triggered when **both** are true: 1. `aof_current_size >= auto-aof-rewrite-min-size` 2. `(aof_current_size - aof_base_size) / aof_base_size * 100 >= auto-aof-rewrite-percentage` With the defaults: the file must be at least 64 MB, and it must have doubled since the last rewrite. Set the percentage to `200` and it must triple. Set it to `0` and automatic rewriting is switched off completely; `min-size` then has no effect. ## Why the minimum size exists Percentages are unstable at small magnitudes. A freshly seeded AOF of a few hundred kilobytes doubles within seconds of normal traffic, and you would fork constantly for no benefit. The minimum turns the percentage rule off until the file is large enough that halving it is actually worth a fork. `64mb` is the default; on a machine with a 50 GB dataset it is far too low, because you will hit it during the first minutes of writes and then rewrite repeatedly against a small baseline. ## Interaction with other persistence children Redis runs at most one persistence child. If the automatic condition fires while a `BGSAVE` (or a replica full-sync fork) is running, Redis does not fork; it sets an internal flag visible as `aof_rewrite_scheduled:1` and starts the rewrite when the current child exits. The same applies to a manual `BGREWRITEAOF`: the command returns success, but the work may not have begun. Monitoring that assumes "command returned, therefore rewriting" will misread this. ## Runtime changes Both settings are `CONFIG SET`-able, so you can raise them during an incident without restarting: ``` CONFIG SET auto-aof-rewrite-percentage 0 # stop automatic rewrites now CONFIG SET auto-aof-rewrite-percentage 200 # rewrite only when the file triples CONFIG REWRITE # persist to the config file ``` Remember `CONFIG REWRITE`, or the change vanishes on restart, which is a classic post-incident surprise. ## Choosing values The tradeoff is straightforward once you name both sides: - **Rewriting more often** keeps the file small, which shortens restart time and disk usage, but pays fork latency and copy-on-write memory more frequently. - **Rewriting less often** amortizes the fork cost, but lets the file grow, which lengthens recovery and risks filling the disk. A practical approach on a large instance: raise `auto-aof-rewrite-min-size` to something meaningful relative to the dataset (for example a multiple of the expected base size), keep or raise the percentage, and measure the resulting rewrite frequency and `latest_fork_usec`. If rewrites still land during peak traffic, disable the automatic trigger and drive `BGREWRITEAOF` from a scheduler during a quiet window, with an alert on `aof_current_size` so you notice if the schedule stops working. ## What these settings do not do They do not affect durability: the loss window is governed by `appendfsync`, not by rewrite frequency. They do not affect how much memory the dataset uses. And they do not throttle a running rewrite; once the child is forked, it runs to completion regardless of the thresholds.