Current location - Health Preservation Learning Network - Slimming men and women - Advantages and disadvantages of RDB and AOF persistence mechanism of redis
Advantages and disadvantages of RDB and AOF persistence mechanism of redis
The significance of redis persistence is mainly aimed at disaster tolerance, and data recovery can actually be classified as a highly available link.

RDB persistence mechanism, which periodically persists the data in redis.

The AOF mechanism treats each write command as a log and writes it to the log file in append-only mode. When redis restarts the comparison, the entire data set can be reconstructed by playing back the instructions written in the AOF log.

If both AOF and RDB persistence mechanisms are used, when redis is restarted, AOF will be used to rebuild the data, because the data of AOF is more complete.

Advantages:

(1)RDB will generate multiple data files, and each data file represents the data of redis at a certain moment. This method of multiple data files is very suitable for cold standby. Files can be stored in the cloud, local disk, etc.

(2)RDB mechanism has little influence on the external read-write service provided by redis, and can maintain the high performance of redis, because the main process of redis only needs a fork subprocess, so that the process can perform disk IO operations to persist RDB.

(3) Compared with AOF persistence mechanism, it is faster to restart and resume the redis process directly based on RDB data files.

Disadvantages:

(1) If you want redis to fail and lose as little data as possible, RDB is not as good as AOF. Because in general, RDB data snapshot files are basically generated every 5 minutes or more. At this point, if there is downtime, all data during this time will be lost.

(2) Every time RDB executes the generation of RDB snapshot data file in the fork subprocess, if the data file is particularly large, the service provided by the client may be suspended for several milliseconds or even seconds.

Advantages:

(1)AOF can better protect data from loss. In general, AOF will perform an fsync operation through a background thread every 1 sec, and lose data at most 1 sec.

(2)AOF log files are written in an append-only way, without the overhead of disk addressing, and the writing performance is very high, and the files are not easy to be damaged. Even if the tail of the file is damaged, it can be easily recovered. Just open the file and delete the damaged data behind it.

(3) Even if the 3)AOF log file is too large, there will be background rewriting operation, which will not affect the reading and writing of the client. Because when the log is rewritten, the instruction will be compressed and a minimum log will be created. When a new log file is created, the old log file will still be written as usual. When a new log file is generated, the instructions written in the old log file later will be merged into the new log file. The new merged log file will be exchanged with the old log file when it is ready. Then the old log file will be deleted.

(4)4)AOF files store executed instructions, so this function is very suitable for emergency recovery of catastrophic misoperation. For example, someone accidentally emptied all the data with the flushall command. As long as the background rewrite does not occur at this time, you can immediately copy the AOF file, delete the last flushall command, and then put the AOF file back, so that all data can be automatically recovered through the recovery mechanism.

Disadvantages:

(1) For the same data, the log file of AOF is usually larger than the data snapshot file of RDB.

(2) After AOF is turned on, the writing QPS supported by Redis service will be lower than that supported by RDB, because AOF is generally configured as fsync log file once per second, and the performance of fsync once per second is still very high.

(3) In the past, there was a bug in AOF, that is, when the data was recovered through the log recorded by AOF, the same data was not recovered. Therefore, the more complex way based on command log/merge/playback like AOF is more fragile and prone to bugs than the way based on RDB to persist a complete data snapshot file at a time. However, in order to avoid the bug caused by rewriting process, AOF does not merge instructions according to the old instruction log every time, but reconstructs instructions according to the data in memory at that time, which is more robust.

Combining the two, AOF is used as the first choice to ensure as little data loss as possible, while RDB is used to recover data more quickly in case of AOP loss or damage.