Understanding Redis Persistence: RDB vs AOF Explained
This article provides a detailed analysis of Redis's two persistence mechanisms—RDB snapshots and AOF logging—covering their core concepts, implementation details, trigger conditions, data safety, performance impact, and recovery speed to help engineers choose the appropriate method for their workloads.
1. Overview
Redis is increasingly used not only as an in‑memory cache but also as a durable data store, prompting the need to persist data to disk so that a restart does not lose cached information.
Redis offers two persistence modes:
2. RDB Persistence Mode
2.1 Core Idea
Creates a snapshot of the current memory state and writes it to disk, providing a full backup of the data.
2.2 Challenges
Obtaining a memory snapshot requires forking a child process that shares the parent’s memory via copy‑on‑write.
Disk I/O during the save operation could block other requests, but RDB saving runs in a separate child process, avoiding impact on the main process.
2.3 RDB File Format
The RDB file consists of a fixed header, version, architecture flag, timestamp, memory size, followed by database data and an EOF marker with a checksum.
Database entries are stored as:
SELECTDB marker indicating the start of a database.
Database number (e.g., 0).
Total key count and expired key count.
Key‑value pairs.
2.4 Trigger Conditions
save 900 1 // after 15 minutes if at least 1 write
save 300 10 // after 5 minutes if at least 10 writes
save 60 10000 // after 1 minute if at least 10000 writesManual triggers:
>save // synchronous RDB save
>bgsave // asynchronous RDB save (default)2.5 Data Safety
If the machine crashes, all data written after the last successful RDB save is lost.
2.6 Core Source (bgsave example)
int rdbSaveBackground(char *filename, rdbSaveInfo *rsi) {
pid_t childpid;
long long start;
if (server.aof_child_pid != -1 || server.rdb_child_pid != -1) return C_ERR;
server.dirty_before_bgsave = server.dirty;
server.lastbgsave_try = time(NULL);
openChildInfoPipe();
start = ustime();
if ((childpid = fork()) == 0) {
closeListeningSockets(0);
redisSetProcTitle("redis-rdb-bgsave");
int retval = rdbSave(filename,rsi);
if (retval == C_OK) sendChildInfo(CHILD_INFO_TYPE_RDB);
exitFromChild(retval == C_OK ? 0 : 1);
} else {
server.stat_fork_time = ustime()-start;
server.rdb_save_time_start = time(NULL);
server.rdb_child_pid = childpid;
server.rdb_child_type = RDB_CHILD_TYPE_DISK;
updateDictResizePolicy();
return C_OK;
}
return C_OK;
}3. AOF Persistence Mode
3.1 Core Idea
Appends every write command received by the server to a log file; recovery replays the commands.
3.2 Challenges
The AOF file can grow large due to redundant commands; Redis periodically rewrites the AOF to eliminate waste.
Write operations happen in the main thread, but the costly fsync is performed by a dedicated background thread, preventing main‑thread blockage.
3.3 File Format
The AOF stores raw Redis command protocol entries.
3.4 Trigger Conditions
Enabled via configuration: appendonly yes # enable AOF Flush policies:
# appendfsync always // flush on every write
appendfsync everysec // flush once per second (default)
# appendfsync no // let OS handle flushing3.5 Performance Impact
Writes occur in the main thread, but fsync runs in a separate thread, so enabling AOF does not severely affect throughput.
3.6 AOF Rewrite
Rewrite removes redundant commands by reconstructing the current dataset into a fresh AOF file, avoiding costly command‑by‑command analysis.
Trigger command:
>bgrewriteaofCommand3.7 Data Safety
Data loss depends on the appendfsync setting:
always : may lose data due to batch flushing after epoll wait.
everysec : typically loses up to 2 seconds of data because a pending flush can be delayed.
no : loss is unpredictable as the kernel decides when to flush.
4. Recovery Speed: RDB vs AOF
RDB restores faster because it loads a compact snapshot, while AOF may contain many redundant commands; however, after an AOF rewrite, the file is compact and recovery speed becomes comparable.
5. Conclusion
The article thoroughly explains both RDB and AOF persistence mechanisms, enabling engineers to select the most suitable approach based on their specific business requirements.
Tencent TDS Service
TDS Service offers client and web front‑end developers and operators an intelligent low‑code platform, cross‑platform development framework, universal release platform, runtime container engine, monitoring and analysis platform, and a security‑privacy compliance suite.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
