Redis 7.2 isn’t just an incremental update; it fundamentally shifts how we think about data persistence and management, particularly with its introduction of RDB-only snapshots.
Let’s see it in action. Imagine you’re running a Redis instance and want to ensure your data is backed up without the overhead of a full AOF rewrite.
redis-cli config set save "60 1 3600 1 900 10"
redis-cli config rewrite
redis-cli --rdb mybackup.rdb
This sets up the standard RDB snapshotting (1 snapshot every 60 seconds if at least 1 key changed, etc.) and then immediately triggers an RDB snapshot to a file named mybackup.rdb. The key here is that the SAVE command, and thus the CONFIG SET save directive, now solely controls RDB snapshots. AOF persistence is managed entirely separately.
The problem Redis 7.2 solves is the historical coupling of RDB and AOF. Previously, if you wanted AOF persistence (for finer-grained durability), you often had to deal with RDB snapshots as well, which could be redundant or even conflict in certain scenarios. AOF also had its own overhead, especially during rewrites.
Internally, Redis 7.2 decouples these. The SAVE command and the save configuration directive are now exclusively for RDB. AOF persistence, including its appendonly yes setting and appendfsync behavior, is managed independently. This means you can choose to have only RDB, only AOF, or both, with much cleaner configuration and execution.
The levers you control are now much more distinct:
- RDB:
save <seconds> <changes>: The core RDB snapshotting configuration. For example,save 3600 1means take an RDB snapshot every 3600 seconds if at least 1 key has changed.dbfilename <filename>: The name of the RDB snapshot file (defaults todump.rdb).dir <directory>: The directory where RDB files are stored.
- AOF:
appendonly yes|no: Enables or disables AOF persistence.appendfilename <filename>: The name of the AOF file (defaults toappendonly.aof).appendfsync <always|everysec|no>: Controls how often AOF writes are flushed to disk.everysecis the typical default, offering a good balance between durability and performance.no-appendfsync-on-rewrite yes|no: A crucial new setting. When set toyes, Redis will not performfsyncoperations on the AOF file during an AOF rewrite. This significantly speeds up rewrites, as the main bottleneck is often disk I/O.
The "why it matters" is about flexibility and performance. For many use cases, especially those where occasional data loss is acceptable (like caching), relying solely on RDB snapshots is simpler and less resource-intensive than managing AOF. The RDB-only mode means you don’t need to worry about AOF file growth or rewrite overhead if RDB meets your durability needs. Conversely, if you need near-real-time durability, you can enable AOF and potentially disable RDB entirely, or configure RDB to run less frequently.
The no-appendfsync-on-rewrite yes setting is a game-changer for AOF performance during rewrites. Previously, a rewrite was a blocking I/O operation that could stall your Redis instance. By allowing fsync to be skipped during the rewrite, Redis can now perform rewrites much more efficiently, reducing the impact on your application’s latency. You’re essentially telling Redis, "I trust that the data being written during the rewrite will eventually get to disk via the normal appendfsync mechanism, so don’t pause everything to fsync it right now during the rewrite process itself."
The most surprising true thing about RDB-only snapshots in 7.2 is that they don’t change the fundamental RDB file format. The SAVE command still produces the exact same RDB data structure. The change is purely in the configuration and operational management of persistence, allowing RDB to be the sole persistence mechanism without any implicit AOF baggage.
The next concept you’ll likely explore is how to precisely tune appendfsync in conjunction with no-appendfsync-on-rewrite for optimal durability-performance trade-offs.