Understanding Redis Persistence: RDB vs AOF and High‑Availability Strategies

The article begins by defining high‑availability in the context of Redis, emphasizing not only continuous service but also data safety and scalability. It outlines four core techniques: persistence, replication, Sentinel, and clustering.

Redis Persistence Overview

Redis stores data in memory, so persistence is required to avoid data loss on process exit. Two persistence methods exist: RDB (snapshot) and AOF (append‑only file). RDB writes periodic snapshots to disk, while AOF logs every write command, offering near‑real‑time durability.

RDB Persistence

Trigger conditions : manual ( save, bgsave) and automatic via save m n configurations.

Manual trigger : save blocks the server; bgsave forks a child process to write the snapshot, allowing the parent to continue serving requests.

Automatic trigger : evaluated every 100 ms by serverCron using the dirty counter and lastsave timestamp. Conditions are now - lastsave > m and dirty >= n.

Execution flow : parent forks, child creates a temporary RDB file, then atomically replaces the old file; the parent updates statistics after receiving the child’s signal.

File details : stored as a compressed binary with fields like REDIS, db_version, SELECTDB sections, EOF, and checksum. Compression uses LZF and applies only to strings longer than 20 bytes.

Loading : on startup Redis loads RDB unless AOF is enabled; loading is blocking.

Common config : save m n, stop-writes-on-bgsave-error, rdbcompression, rdbchecksum, dbfilename, dir.

AOF Persistence

Enabling : set appendonly yes in the config.

Workflow : write commands are appended to an in‑memory buffer ( aof_buf), then flushed to disk according to appendfsync policy (always, everysec, no).

File rewrite : bgrewriteaof forks a child to rewrite the AOF, compressing it by dropping expired keys, merging redundant commands, and respecting a rewrite buffer ( aof_rewrite_buf) for writes occurring during rewrite.

Triggering rewrite : manual via bgrewriteaof or automatic based on auto-aof-rewrite-min-size and auto-aof-rewrite-percentage.

Loading : if AOF is enabled, it is loaded first; incomplete tails are ignored when aof-load-truncated is on.

Common config : appendfilename, appendfsync everysec, no-appendfsync-on-rewrite, auto-aof-rewrite-percentage, auto-aof-rewrite-min-size, aof-load-truncated.

Choosing a Persistence Strategy

RDB offers compact files and fast recovery, suitable when occasional data loss is acceptable. AOF provides second‑level durability but larger files and slower recovery. Production setups often combine both, or use RDB on masters for performance and AOF on slaves for safety. Consider factors such as data loss tolerance, write load, backup frequency, and disaster‑recovery requirements.

Operational Concerns

Fork‑related blocking : large memory footprints increase fork time, potentially causing noticeable latency. Keep single‑node memory under ~10 GB or monitor latest_fork_usec.

AOF append blocking : when appendfsync everysec cannot complete within 2 seconds, the main thread blocks. Monitor aof_delayed_fsync and system I/O metrics.

Info commands : info persistence and info stats expose status such as rdb_last_bgsave_status, aof_enabled, and latest_fork_usec.

Summary

Persistence backs up Redis data to disk, complementing replication.

RDB creates snapshots via bgsave with configurable triggers and minimal runtime impact.

AOF logs every write, with configurable sync policies and periodic rewrites to keep file size manageable.

Choosing between RDB, AOF, or both depends on performance, durability, and operational constraints, while being aware of fork and I/O blocking issues.