Redis Persistence

official site:
https://redis.io/topics/persistence

Redis provides a different range of persistence options:

The RDB persistence performs point-in-time snapshots of your dataset at specified intervals.

the AOF persistence logs every write operation received by the server, that will be played again at server startup, reconstructing the original dataset. Commands are logged using the same format as the Redis protocol itself, in an append-only fashion. Redis is able to rewrite the log on background when it gets too big.

RDB advantages

RDB is a very compact single-file point-in-time representation of your Redis data.

RDB files are perfect for backups.

For instance you may want to archive your RDB files every hour for the latest 24 hours, and to save an RDB snapshot every day for 30 days. This allows you to easily restore different versions of the data set in case of disasters.

RDB is very good at disaster recovery.

RDB allows faster restarts with big datasets compared to AOF.

RDB disadvantages

RDB is NOT good if you need to minimize the chance of data loss in case Redis stops working (for example after a power outage).

RDB needs to fork() often in order to persist on disk using a child process. Fork() can be time consuming if the dataset is big,

AOF advantages

Using AOF Redis is much more durable: you can have different fsync policies: no fsync at all, fsync every second, fsync at every query.

The AOF log is an append only log, so there are no seeks, nor corruption problems if there is a power outage.

Redis is able to automatically rewrite the AOF in background when it gets too big.

AOF contains a log of all the operations one after the other in an easy to understand and parse format.

AOF disadvantages

AOF files are usually bigger than the equivalent RDB files for the same dataset.

AOF can be slower than RDB depending on the exact fsync policy.

Ok, so what should I use?

The general indication is that you should use both persistence methods if you want a degree of data safety comparable to what PostgreSQL can provide you.
If you care a lot about your data, but still can live with a few minutes of data loss in case of disasters, you can simply use RDB alone.
There are many users using AOF alone, but we discourage it since to have an RDB snapshot from time to time is a great idea for doing database backups, for faster restarts, and in the event of bugs in the AOF engine.
Note: for all these reasons we'll likely end up unifying AOF and RDB into a single persistence model in the future (long term plan).
The following sections will illustrate a few more details about the two persistence models.

By default Redis saves snapshots of the dataset on disk, in a binary file called dump.rdb. You can configure Redis to have it save the dataset every N seconds if there are at least M changes in the dataset, or you can manually call the SAVE or BGSAVE commands.

For example, this configuration will make Redis automatically dump the dataset to disk every 60 seconds if at least 1000 keys changed:

This strategy is known as snapshotting.

How it works

Whenever Redis needs to dump the dataset to disk, this is what happens:

• Redis forks. We now have a child and a parent process.

• The child starts to write the dataset to a temporary RDB file.

• When the child is done writing the new RDB file, it replaces the old one.

This method allows Redis to benefit from copy-on-write semantics.

Append-only file

Snapshotting is not very durable. If your computer running Redis stops, your power line fails, or you accidentally kill -9 your instance, the latest data written on Redis will get lost. While this may not be a big deal for some applications, there are use cases for full durability, and in these cases Redis was not a viable option.
The append-only file is an alternative, fully-durable strategy for Redis. It became available in version 1.1.

How durable is the append only file?

You can configure how many times Redis will fsync data on disk. There are three options:

• fsync every time a new command is appended to the AOF. Very very slow, very safe.

• fsync every second. Fast enough (in 2.4 likely to be as fast as snapshotting), and you can lose 1 second of data if there is a disaster.

• Never fsync, just put your data in the hands of the Operating System. The faster and less safe method.

The suggested (and default) policy is to fsync every second. It is both very fast and pretty safe. The always policy is very slow in practice (although it was improved in Redis 2.0) – there is no way to make fsync faster than it is.

What should I do if my AOF gets corrupted?

It is possible that the server crashes while writing the AOF file (this still should never lead to inconsistencies), corrupting the file in a way that is no longer loadable by Redis. When this happens you can fix this problem using the following procedure:

• Make a backup copy of your AOF file.

• Fix the original file using the redis-check-aof tool that ships with Redis:

  $ redis-check-aof --fix<filename></filename>

• Optionally use diff -u to check what is the difference between two files.

• Restart the server with the fixed file.

How it works

Log rewriting uses the same copy-on-write trick already in use for snapshotting. This is how it works:

• Redis forks, so now we have a child and a parent process.

• The child starts writing the new AOF in a temporary file.

• The parent accumulates all the new changes in an in-memory buffer (but at the same time it writes the new changes in the old append-only file, so if the rewriting fails, we are safe).

• When the child is done rewriting the file, the parent gets a signal, and appends the in-memory buffer at the end of the file generated by the child.

• Profit! Now Redis atomically renames the old file into the new one, and starts appending new data into the new file.

How I can switch to AOF, if I'm currently using dump.rdb snapshots?

There is a different procedure to do this in Redis 2.0 and Redis 2.2, as you can guess it's simpler in Redis 2.2 and does not require a restart at all.