Mastering Redis Persistence: When to Use RDB vs AOF for High Availability

Starting this series, we introduce Redis high‑availability mechanisms. To achieve high availability, Redis relies on data persistence, master‑slave replication, automatic failover, and clustering.

Data persistence

Master‑slave replication

Automatic failover

Clustering

We begin with the foundation of Redis high‑availability: data persistence. Both replication and failover depend on persistence, which also serves as backup to protect data integrity.

Redis stores data in memory; a crash would lose everything, so persisting data to disk is essential for safety and quick recovery.

Redis offers two persistence methods:

RDB – creates a snapshot file

AOF – appends every write command to a log file

RDB

Introduction

RDB (Redis Database Backup) is a snapshot of the entire dataset.

You can generate an RDB file with the save or bgsave command, which writes a near‑complete snapshot to disk.

Advantages:

RDB files are compressed, making them smaller than the in‑memory dataset.

Loading an RDB file after a crash is fast, enabling rapid data restoration.

Disadvantages:

Since it is a point‑in‑time snapshot, some recent writes may be missing.

Generating an RDB file consumes significant CPU and memory resources.

Typical use cases:

Full data synchronization for master‑slave replication

Database backups

Scenarios where occasional data loss is acceptable and fast recovery is needed after a crash

Scheduled RDB Generation

Redis can automatically trigger RDB creation based on write activity:

# 最近15分钟内 至少产生1次写入
save 900 1
# 最近5分钟内 至少产生10次写入
save 300 10
# 最近1分钟内 至少产生10000次写入
save 60 10000

If any condition is met, Redis generates a new RDB file, reducing data divergence.

Copy‑On‑Write (COW)

Both save and bgsave can create RDB files, but save runs in the foreground and blocks the entire instance until the snapshot finishes, which is unacceptable for large instances.

Therefore, bgsave is preferred: it forks a child process to write the RDB file while the parent continues handling client requests.

The fork operation uses the operating system’s Copy‑On‑Write mechanism. The child receives a copy of the parent’s memory pages; while copying, the parent is blocked and CPU usage spikes. After the fork, the child writes the snapshot, and the parent resumes processing requests, allocating new memory pages as needed, gradually separating the memory spaces.

During RDB generation, Redis may temporarily require up to twice the memory size.

You can monitor the fork duration with the info command and ensure the server has sufficient CPU and memory resources.

AOF

Introduction

AOF (Append Only File) records every write command with full details, appending them to a log in real time.

Enable AOF in the configuration file:

# 开启AOF
appendonly yes

# AOF文件名
appendfilename "appendonly.aof"

# 文件刷盘方式
appendfsync everysec

Sync Policies

appendfsync always : flush to disk after every write – highest safety, highest I/O cost.

appendfsync everysec : flush once per second – balances performance and safety (max 1 second data loss).

appendfsync no : rely on OS flushing – lowest I/O impact, lowest safety.

AOF provides more up‑to‑date data than RDB, allowing near‑complete recovery, but it also has drawbacks:

The file grows continuously over time.

Frequent flushing can increase disk I/O and affect performance.

AOF Rewrite

When the AOF file becomes large, Redis can rewrite it to a compact form, scanning the dataset and generating a new, smaller AOF file. This process also consumes CPU.

# AOF文件距离上次文件增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写
auto-aof-rewrite-min-size 64mb

AOF is ideal for workloads that cannot tolerate data loss, such as financial transactions.

Performance Impact

If appendfsync always is used, write performance degrades sharply because each command must be flushed to disk. The common compromise is appendfsync everysec, which offers good performance while limiting potential data loss to one second.

Conclusion

RDB and AOF each have strengths: RDB is compact and fast to load, suitable for backups and full‑sync scenarios; AOF provides finer‑grained durability, suitable for data‑sensitive applications. Choosing the right persistence method—or combining both—ensures Redis data safety while meeting performance requirements.