Persistence and Durability

For operatorsPersistence and Durability

#Course Structure

This tutorial is part of the Running Redis at Scale course. You can jump to any section:

Introduction to Running Redis at Scale
Talking to Redis - CLI, clients, and tuning
Persistence and Durability ← You are here
High Availability - Replication and Sentinel
Scalability - Redis Cluster
Observability - Metrics and troubleshooting
Course Conclusion

As you know, Redis serves all data directly from memory. But Redis is also capable of persisting data to disk. Persistence preserves data in the event of a server restart.

In this tutorial, we'll look at the options for persisting data to disk. You'll learn about RDB snapshots and AOF (Append-Only File), and then do a hands-on exercise setting up persistence for your Redis instance.

#Persistence Options in Redis

Video

If a Redis server that only stores data in RAM is restarted, all data is lost. To prevent such data loss, there needs to be some mechanism for persisting the data to disk; Redis provides two of them: snapshotting and an append-only file, or AOF. You can configure your Redis instances to use either of the two, or a combination of both.

#RDB Snapshots

When a snapshot is created, the entire point-in-time view of the dataset is written to persistent storage in a compact .rdb file. You can set up recurring backups, for example every 1, 12, or 24 hours and use these backups to easily restore different versions of the data set in case of disasters. You can also use these snapshots to create a clone of the server, or simply leave them in place for a future restart.

Creating a .rdb file requires a lot of disk I/O. If performed in the main Redis process, this would reduce the server's performance. That's why this work is done by a forked child process. But even forking can be time-consuming if the dataset is large. This may result in decreased performance or in Redis failing to serve clients for a few milliseconds or even up to a second for very large datasets. Understanding this should help you decide whether this solution makes sense for your requirements.

You can configure the name and location of the .rdb file with the dbfilename and dir configuration directives, either through the redis.conf file, or through the redis-cli as explained in Talking to Redis. And of course you can configure how often you want to create a snapshot.

As an example, this configuration will make Redis automatically dump the dataset to disk every 60 seconds if at least 1000 keys changed in that period. While snapshotting is a great strategy for the use cases explained above, it leaves a huge possibility for data loss. You can configure snapshots to run every few minutes, or after X writes against the database, but if the server crashes you lose all the writes since the last snapshot was taken. In many use cases, that kind of data loss can be acceptable, but in many others it is absolutely not. For all of those other use cases Redis offers the AOF persistence option.

#Append-Only File (AOF)

AOF, or append-only file works by logging every incoming write command to disk as it happens. These commands can then be replayed at server startup, to reconstruct the original dataset. Commands are logged using the same format as the Redis protocol itself, in an append-only fashion. The AOF approach provides greater durability than snapshotting, and allows you to configure how often file syncs happen.

Depending on your durability requirements (or how much data you can afford to lose), you can choose which fsync policy is the best for your use case:

fsync every write: The safest policy: The write is acknowledged to the client only after it has been written to the AOF file and flushed to disk. Since in this approach we are writing to disk synchronously, we can expect a much higher latency than usual.
fsync every second: The default policy. Fsync is performed asynchronously, in a background thread, so write performance is still high. Choose this option if you need high performance and can afford to lose up to one second worth of writes.
no fsync: In this case Redis will log the command to the file descriptor, but will not force the OS to flush the data to disk. If the OS crashes we can lose a few seconds of data (Normally Linux will flush data every 30 seconds with this configuration, but it's up to the kernel's exact tuning.).

The relevant configuration directives for AOF are shown on the screen. AOF contains a log of all the operations that modified the database in a format that's easy to understand and parse. When the file gets too big, Redis can automatically rewrite it in the background, compacting it in a way that only the latest state of the data is preserved.

#Exercise: Configuring Persistence

By default, Redis will save a snapshot of your database every hour if at least one key has changed, every five minutes if at least 100 keys have changed, or every 60 seconds if at least 10000 keys have changed.

Let's update this to a simplified hypothetical scenario where we want to save a snapshot if three keys have been modified in 20 seconds.

#Step 1: Create a Configuration File

Create a directory named 2.2 and in it prepare a redis.conf file.

The redis.conf file should specify a filename that will be used for the rdb file and a directive that will trigger the creation of a snapshot if 3 keys have been modified in 20 seconds, as described above.

#Step 2: Start Redis with RDB Snapshots

In the 2.2 directory, start a Redis server - passing it the redis.conf configuration file you just created.

In a separate terminal tab use the redis-cli to create three random keys, one after the other. For example:

Run the ls command in the first terminal to list all the files in the 2.2 directory. What changed?

#Step 3: Enable AOF Persistence

Now we're ready to take our persistence a level higher and set up an AOF file. Modify your redis.conf file so that the server will log every new write command and force writing it to disk.

Be careful! We have a running server and we want this configuration to be applied without restarting it.

In order for these settings to be persisted to the redis.conf file we need to save them:

#Step 4: Verify AOF is Working

Create a few random keys through redis-cli. Check the contents of the directory 2.2 again. What changed?

#Step 5: Test Persistence After Restart

As a final step, restart the Redis server process (you can press Ctrl+C in the terminal to stop the process and re-run it again). If you run the SCAN 0 command you will see that all the keys you created are still in the database, even though we restarted the process.

Next: High Availability →