Mastering Redis AOF: How Append‑Only Files Ensure Data Persistence

1 Introduction

AOF (Append Only File) persistence stores a sequential log of Redis commands that modify memory, allowing the server to replay the log after a crash and rebuild the in‑memory data structures, similar to MySQL's relay log.

Compared with RDB snapshots, AOF provides real‑time durability and is now the mainstream Redis persistence method.

2 AOF Implementation Logging

2.1 Enable AOF Logging

Enable AOF logging: set appendonly yes in redis.conf (default is no).

Configure default file name: set appendfilename "appendonly.aof" in redis.conf.

2.2 Execution Process

2.2.1 Append write commands to the aof_buf buffer

When Redis receives a command such as set keyName someValue , it first writes the data to memory and then appends the command to the AOF file in the Redis protocol format:

*3 indicates three parts (command, key, value). Each part starts with $ followed by the byte length.

The length prefix (e.g., $3 ) specifies the number of characters of the following element, such as the command name “set”.

Typical AOF snippet (comments added for clarity):

<code># vim appendonly.aof
# execute set key value
*3
$3
set
$9
user_name
$5
brand

# execute mset key1 1 key2 2 key33 3
*7
$4
mset
$4
key1
$1
1
$4
key2
$1
2
$5
key33
$1
3
</code>

2.2.2 Sync strategies for the AOF buffer

Redis writes commands to the aof_buf buffer first to avoid blocking the single‑threaded event loop on every disk write. The following configuration options control how the buffer is synchronized to disk:

appendfsync mode

<code>appendfsync always   # write to disk after every command (strong durability, slow)
appendfsync everysec # write to disk every second (balanced, recommended)
appendfsync no       # rely on OS sync (fast, but no real‑time durability)
</code>

no-appendfsync-on-rewrite

<code># default: no
# optional: yes or no
no-appendfsync-on-rewrite yes
</code>

2.2.3 AOF Rewrite (compression)

When the AOF file grows large, Redis rewrites it to produce a smaller file. The rewrite removes expired data, deletes no‑op commands, merges multiple writes, and splits very large commands to keep each command size reasonable.

2.2.4 AOF Rewrite configuration

auto-aof-rewrite-percentage – triggers rewrite when the file size grows by the given percentage (default 100%).

<code># default: 100
auto-aof-rewrite-percentage 100
</code>

auto-aof-rewrite-min-size – minimum file size required to trigger a rewrite (default 64mb).

<code># default: 64mb
auto-aof-rewrite-min-size 64mb
</code>

2.2.5 Data recovery on restart

When Redis restarts, it loads the AOF file (or RDB if AOF is disabled) to recover data.

If both AOF and RDB exist, AOF is loaded first.

If AOF is disabled, Redis loads the RDB snapshot.

Successful load leads to a normal restart; if no persistence files exist, Redis starts without data.

If loading fails, Redis aborts startup and prints an error.

2.3 Comparison of RDB and AOF, and hybrid persistence

RDB provides point‑in‑time snapshots, while AOF records every write operation. Each has trade‑offs: RDB may lose recent data, AOF replay can be slow for large datasets. Redis 4.0 introduced hybrid persistence, which stores an RDB snapshot followed by incremental AOF logs. This combines fast snapshot loading with minimal replay overhead.

To enable hybrid mode:

<code>aof-use-rdb-preamble yes
</code>

Conclusion

RDB snapshots capture the memory state at a specific time and use forked child processes to minimize impact on reads/writes, but frequent snapshots increase disk I/O and block the main thread.

AOF logs sequential write commands; replay restores data, and sync policies balance durability and performance.

If occasional minute‑level data loss is acceptable, RDB alone may suffice.

When using only AOF, the everysec sync option offers a good reliability‑performance trade‑off.

For zero‑data‑loss requirements, combining RDB snapshots with AOF (or hybrid persistence) is the recommended approach.