Compare the two persistence methods of redis data

  • 2020-05-17 06:54:56
  • OfStack

1. Concept introduction

redis provides two modes of persistence, RDB (Redis DataBase) and AOF (Apend Only File).

RDB way

The RDB method is a snapshot persistence method that persists data at a certain time to disk.

The & # 8226; In the process of data persistence, redis will first write the data to a temporary file, which will be used to replace the last persistent file when the persistence process is over. It is this feature that allows you to take a backup at any time, since the snapshot file is always fully available.
The & # 8226; In RDB mode, redis creates a separate (fork) subprocess for persistence, and the main process does not do any IO operations, thus ensuring the extremely high performance of redis.
The & # 8226; If large-scale data recovery is required and is not sensitive to the integrity of data recovery, RDB is more efficient than AOF.

AOF way

The AOF mode is to record the written instructions that have been executed, and execute the instructions one more time in the sequence from front to back when the data is recovered.

The & # 8226; AOF command to redis supplemental agreement save each write operation until the end of the file. Redis can rewrite AOF file for the background, and makes the AOF file size not too big. The default AOF persistence strategy is fsync1 per second (fsync refers to write instructions records in the cache to disk), because in this case, the redis can still maintain good processing performance, even redis fault, also will only lose a second data recently.
The & # 8226; It doesn't matter if when you append a log, you happen to encounter a situation where disk space is full, inode is full, or the power goes out, resulting in incomplete log writes. redis provides the redis-check-aof tool, which can be used for log repair.
The & # 8226; Because of the append method, the AOF file will become larger and larger if no processing is done. For this reason, redis provides the AOF file rewrite (rewrite) mechanism, which means that when the size of AOF file exceeds the set threshold, redis will start the content compression of AOF file, and only the minimum instruction set that can recover data will be retained. For example, if we call the INCR instruction 100 times, we need to store 100 instructions in the AOF file. However, this is obviously inefficient. We can combine the 100 instructions into one SET instruction, which is the principle of rewriting mechanism.
The & # 8226; In the rewriting of AOF, the process of writing temporary files first and replacing them after completion is still adopted, so the availability of AOF files will not be affected by power failure, full disk, etc.

2. Advantages and disadvantages of the two approaches

1. RDB way

The & # 8226; Advantages:

RDB is a compact single 1 file, it preserved the some point data set, very suitable for a backup data sets, such as you can in each hour to save 1 data that in the past 24 hours, at the same time every day to save data in the past 30 days, even out of the question you can restore to a different version of the data set according to demand.
2.RDB is a compact single 1 file, easy to transfer and suitable for disaster recovery.
3. When RDB saves RDB file, all the parent process needs to do is fork to produce a child process, and the following work is all done by the child process. The parent process does not need to do other IO operations, so RDB persistence can maximize the performance of redis.
4. Compared with AOF, RDB mode is faster to recover large data sets.

The & # 8226; Disadvantages:

1. When Redis is down unexpectedly, several minutes of data may be lost (depending on the configured save time point). The RDB method needs to save the entire data set of Jane, which is a heavy work. It usually needs to be set for 5 minutes or longer to do a complete save.
2.RDB often needs fork child processes to save the data set to the hard disk. When the data set is large, the process of fork is very time-consuming, which may cause Redis to fail to respond to client requests within 1 millisecond; if the data set is large and CPU's performance is not very good, this situation will last longer.

2. AOF way

The & # 8226; advantages

Using AOF makes Redis data more durable: you can use a different fsync policy: no fsync, fsync per second, fsync per write. Using the default fsync policy per second,Redis still performs very well (fsync is handled by background threads, the main thread tries to handle client requests), and you lose up to 1 second of data in case of a failure.
2. The AOF file is an append-only log file, so you don't need to write seek. You can use the redis-check-aof tool to fix the problem even if you don't execute the full write command for some reason (disk space is full, the write is down, etc.).
3.Redis can automatically rewrite AOF in the background when the size of the AOF file becomes too large: the rewritten new AOF file contains the minimum set of commands needed to restore the current data set. The whole rewrite operation is absolutely safe, because Redis continues to append the command to the existing AOF file during the creation of a new AOF file, and the existing AOF file will not be lost even if an outage occurs during the rewrite process. Once the new AOF file has been created, Redis will switch from the old AOF file to the new AOF file, and begin to append the new AOF file.
4. The AOF file contains all writes to the database in an orderly manner, and these writes are stored in the Redis format, making the contents of the AOF file easy to read and easy to analyze. Exporting AOF is also very simple: for example, if you accidentally execute the FLUSHALL command, but as long as the AOF file is not overwritten, simply stop the server, remove the FLUSHALL command at the end of the AOF file, and restart Redis to restore the data set to the state it was before FLUSHALL was executed.

The & # 8226; disadvantages

1. For the same data set, the size of the AOF file is usually larger than that of the RDB file.
2. Depending on the fsync policy used, the speed of AOF may be slower than that of RDB. The performance of fsync per second is still very high in the 1 normal case, while turning off fsync makes AOF as fast as RDB 1, even under high load. However, when handling large write loads, RDB can provide a more guaranteed maximum latency.

3. Configuration method

1. Configuration of RDB

By default, snapshot rdb is persisted, and the data in memory is written as a snapshot to a binary file. The default file name is dump.rdb
redis. conf configuration:


save 900 1 
save 300 10
save 60 10000

The above is the default configuration: within 900 seconds, if more than 1 key is modified, the snapshot is saved;
If more than 10 key are modified within 300 seconds, a snapshot is initiated;
Within 1 minute, if 10,000 key are modified, a snapshot is initiated.

This method cannot guarantee the data persistence completely, because it is regularly saved, so when redis service down is lost, 1 part of the data will be lost. Moreover, large amount of data and many write operations will cause a large number of disk IO operations, which will affect the performance.

Therefore, if both methods are turned on at the same time and data is recovered, the database should not be recovered using rdb persistence.

2. AOF configuration

With aof for persistence, each write command is appended to appendonly.aof via the write function.
Configuration mode: start aof persistence mode

appendonly yes

Resources: http: / / redis io/topics/persistence


Related articles: