Which persistence strategy is good for redis?

Redis provides a variety of persistence methods at different levels:

RDB persistence can generate data sets within a specified time interval. Point-in-time snapshot.

AOF persistently records all write operation commands executed by the server, and restores the data set by re-executing these commands when the server starts. All commands in the AOF file are saved in the Redis protocol format, and new commands will be appended to the end of the file. Redis can also rewrite the AOF file in the background so that the size of the AOF file does not exceed the actual size required to save the data set state.

Redis can also use AOF persistence and RDB persistence at the same time. In this case, when Redis restarts, it will give priority to using the AOF file to restore the data set, because the data set saved by the AOF file is usually more complete than the data set saved by the RDB file.

You can even turn off persistence so that the data only exists while the server is running.

RDB knowledge points

Advantages of RDB

RDB is a very compact file that saves Redis data set at a certain point in time. This type of file is ideal for backup purposes: for example, you could back up an RDB file every hour for the last 24 hours, and also back up an RDB file every day of the month. This way, even if you encounter a problem, you can always restore the data set to a different version.

RDB is very suitable for disaster recovery: it has only one file, and the contents are very compact, and it can be transferred (after encryption) to other data centers, or to Amazon S3.

RDB can maximize the performance of Redis: the only thing the parent process has to do when saving the RDB file is to fork out a child process, and then the child process will handle all the subsequent saving work, and the parent process does not need to perform Any disk I/O operations.

RDB is faster than AOF when restoring large data sets.

Disadvantages of RDB

If you need to minimize data loss in the event of a server failure, then RDB is not for you. Although Redis allows you to set different save points to control the frequency of saving RDB files, it is not an easy operation because RDB files need to save the state of the entire data set. So you may save the RDB file at least once every 5 minutes. In this case, in the event of an outage, you may lose several minutes of data.

Every time the RDB is saved, Redis must fork() a child process, and the child process will perform the actual persistence work. When the data set is large, fork() may be very time-consuming, causing the server to stop processing the client within a certain millisecond; if the data set is very large and the CPU time is very tight, then this stop time may even be longer. for a full second. Although AOF rewriting also requires fork(), no matter how long the execution interval of AOF rewriting is, there will be no loss in data durability.

AOF knowledge points

Advantages of AOF

Using AOF persistence will make Redis very durable (much more durable): You can set different fsync strategies, such as no fsync, fsync once every second, or fsync every time a write command is executed. The default policy of AOF is to fsync once per second. Under this configuration, Redis can still maintain good performance, and even if a failure occurs, only one second of data will be lost at most (fsync will be executed in a background thread, so The main thread can continue to work hard processing command requests).

The AOF file is a log file that only performs append operations (append only log), so writing to the AOF file does not require seeking, even if the log contains incomplete commands for some reasons. (For example, the disk is full when writing, the writing is stopped midway, etc.), the redis-check-aof tool can also easily fix this problem.

Redis can automatically rewrite the 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 data set. The entire rewriting operation is absolutely safe, because Redis will continue to append commands to the existing AOF file during the process of creating a new AOF file. Even if there is a shutdown during the rewriting process, the existing AOF file will not be lost. . Once the new AOF file is created, Redis will switch from the old AOF file to the new AOF file and start appending to the new AOF file.

The AOF file saves all write operations performed on the database in an orderly manner. These write operations are saved in the format of the Redis protocol, so the content of the AOF file is very easy to read and analyze the file ( parse) is also very easy. Exporting (exporting) AOF files is also very simple: for example, if you accidentally execute the FLUSHALL command, but as long as the AOF file has not been overwritten, then just stop the server, remove the FLUSHALL command at the end of the AOF file, and restart Redis. You can restore the data set to the state before FLUSHALL was executed.

Disadvantages of AOF

For the same data set, the size of the AOF file is usually larger than the size of the RDB file.

Depending on the fsync strategy used, AOF may be slower than RDB. Under normal circumstances, fsync performance per second is still very high, and turning off fsync can make AOF as fast as RDB, even under heavy load. However, RDB can provide a more guaranteed maximum latency when handling huge write loads.

AOF has had such a bug in the past: due to individual commands, when the AOF file is reloaded, the data set cannot be restored to the original state when it was saved. (For example, the blocking command BRPOPLPUSH once caused such a bug.) Tests have been added to the test suite for this situation: they automatically generate random, complex data sets and reload these data to ensure that everything normal. Although this kind of bug is not common in AOF files, in comparison, it is almost impossible for RDB to have this kind of bug.

For more Redis-related technical articles, please visit the Redis Tutorial column to learn!

The above is the detailed content of Which persistence strategy is good for redis?. For more information, please follow other related articles on the PHP Chinese website!