Redis Persistence Detailed

Preface

In the Redis database, we know that Redis is not only saving data to memory, but also synchronizing data to disk, which is one of the differences between Redis and Memcache, which is the persistence of Redis and the persistence of Redis with RDB and aof two ways, Let's take a look at the details below.

One, Redis persistence mode

RDB persistence can generate a point-in-time snapshot of a dataset (Point-in-time snapshot) within a specified time interval.

The AOF persists all the write commands that the server performs and restores the dataset by re-executing the commands when the server starts.

Second, the Redis persistence mode comparisonRDB Benefits:

• An RDB is a very compact file that holds the data set of a Redis at a point in time.
  This file is ideal for use in backup, disaster recovery, and other scenarios

• An RDB maximizes the performance of Redis: The only thing the parent process has to do when saving an Rdb file is to fork out a child process, and the child process will handle all subsequent save work, and the parent process does not have to perform any disk I/O operations.

• An RDB recovers a large data set faster than AOF.

Rdb Disadvantages:

• If you need to avoid losing data when the server fails, the RDB is not for you.
  Although Redis allows you to set different savepoint (save point) to control how often an RDB file is saved, it is not an easy operation because the Rdb file needs to preserve the state of the entire dataset. Therefore, you may be able to save the RDB file at least 5 minutes. In this case, you may lose several minutes of data in the event of a failure.

• Each time you save an RDB, Redis will fork () out a subprocess and perform the actual persistence work by the child process.
  fork () can be time-consuming when the dataset is large, causing the server to stop processing the client within a millisecond;
  If the data set is huge and the CPU time is very tight, the stop time may even be a full second.
  Although the AOF rewrite also requires fork () , there is no loss of data durability regardless of the length of the AOF rewrite execution interval.

aof Advantages:

• Using the AOF persistence Default policy of Fsync once per second, in this configuration, Redis can still maintain good performance, and even if there is a failure, the maximum loss of one second of data (Fsync will be executed in the background thread, so the main thread can continue to work hard to handle the command request).

• The AOF file is a log file that only appends operations (append only log),
  Therefore, the write to the AOF file does not require seek,
  The Redis-check-aof tool can easily fix this problem even if the log contains incomplete commands for some reason (such as a write-on disk full, write-down, etc.).

• Redis can automatically override AOF in the background when the AOF file size becomes too large:
  The rewritten new AOF file contains the minimum set of commands required to restore the current dataset.
  The entire rewrite operation is absolutely secure, as Redis will continue to append commands to the existing AOF file during the creation of the new AOF file, and the existing AOF files will not be lost even if there is an outage during the rewrite.
  Once the new AOF file is created, Redis switches from the old AOF file to the new AOF file and begins appending to the new AOF file.

• The AOF file preserves all write operations performed on the database in an orderly manner, and these writes are saved in the format of the Redis protocol.
  So the content of the AOF file is very easy to read and it is easy to analyze the file. Exporting AOF files is also very simple

aof Disadvantages:

• For the same dataset, the volume of the AOF file is usually larger than the size of the RDB file.

• Depending on the fsync policy you are using, the AOF may be slower than the RDB. In general, the performance of Fsync per second is still very high, while closing Fsync can make AOF as fast as an RDB, even under high load. However, the RDB can provide a more guaranteed maximum delay time (latency) when handling large write loads.

• AOF has been a bug in the past: Because of the reason of individual commands, the AOF file cannot be restored as it was when the data set was reloaded. (for example, a blocking command has caused a bug like this.) The test suite adds tests to this situation: they automatically generate random, complex datasets, and re-load the data to make sure everything is fine. Although this bug is not common in AOF files, it is almost impossible for an RDB to appear in comparison.

third, the RDB to save the data process

1. Redis calls the fork () child process, with both the parent and child processes.

2. The child process writes the dataset to a temporary RDB file.

3. When a child process finishes writing to the new Rdb file, Redis replaces the original Rdb file with the new Rdb file and deletes the old Rdb file

iv. configuration of the Rdb snapshot

In the configuration file redis.conf of Redis

Save 60 1000

Note: At least 1000 keys have been changed in 60 seconds to save the data

by default, Redis saves a db snapshot in the name Dump.rdb Binary files.

v. AOF persistence process

1. Redis executes fork () and now has both parent and child processes.

2. The child process begins writing the contents of the new AOF file to a temporary file.

3. For all newly executed write commands, the parent process accumulates them into a memory cache while appending the changes to the end of the existing AOF file:
   This allows the existing AOF files to be safe even if there is an outage in the middle of the rewrite.

4. When a child process finishes rewriting work, it sends a signal to the parent process that the parent process appends all the data in the memory cache to the end of the new AOF file after it receives the signal.

5. Now Redis atomically replaces the old file with the new file, and all commands are appended directly to the end of the new AOF file.

vi. aof Persistent configuration

[[email protected] ~]# grep append /etc/ redis.conf #       at the date of writing  These commands are: set setnx setex appendappendonly no# the name  of the append only file  (default:  "appendonly.aof") appendfilename  " Appendonly.aof "# always: fsync after every write to the append  only log. slow, safest.# appendfsync alwaysappendfsync everysec#  appendfsync no# the same as  "Appendfsync none" . in practical  terms, this means that it isno-appendfsync-on-rewrite no# automatic  Rewrite of the append only file. 

change appendonly on to Yes after AOF persistence configuration is complete , it is not easy to feel. Haha, the configuration is very simple the key is that theoretical knowledge should be understood.

Through the configuration file we see AOF's default Fsync policy with three options

Appendfsync always executes Fsyncappendfsync everysec #每秒执行一次fsyncappendfsync no #从不执行fsync when you #每次有新命令追加到 the AOF file

Well, to do a summary, there are two types of redis persistence, the above detailed comparison of the pros and cons of the two, the reader can be more business needs a reasonable choice for their own persistence, the personal feeling aof a bit like a MySQL binary log, is not to save the data is only recorded to execute the command, This blog post to the end, if you have any questions please leave a message!

This article from "Small Building-home" blog, declined reprint!

Redis Persistence Detailed