1.AOFpersistence

AOF persistence records every write and delete operation processed by the server in the form of logs. The query operation is not recorded in the form of text. You can open the file to see detailed operation records.

1.1 AOFThe advantage of

  1. This mechanism can lead to higher data security, that is, data persistence. Redis provides three synchronization policies: synchronization per second (the default policy), synchronization per change, and no synchronization. In fact, synchronization per second is also done asynchronously, and it is very efficient, except that if the system goes down, the data modified within a second will be lost. With each change synchronization, we can think of it as synchronous persistence, meaning that every data change that occurs is recorded to disk immediately. Predictably, this approach is the least efficient. As for asynchrony, needless to say, I think everyone understands it correctly.

  2. Because the mechanism writes log files in append mode, the existing content in log files will not be damaged even if the log file is down. However, if the system crashes after only writing half of the data, don’t worry. Before the next Redis startup, we can use the Redis-check-aOF tool to help us solve the problem of data consistency.

  3. Redis can automatically rewrite the AOF in the background when 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 entire rewrite operation is absolutely safe because Redis continues to append commands to existing AOF files while creating new AOF files, and the existing AOF files will not be lost even if an outage occurs during the rewrite. Once the new AOF file is created, Redis switches from the old AOF file to the new AOF file and starts appending the new AOF file.

  4. AOF includes a well-formatted, easy-to-understand log file for recording all changes. In fact, we can also use this file to complete data reconstruction

1.2 AOFThe disadvantage of

  1. For the same number of data sets,AOFFiles are usually greater thanRDBFile.RDBThe speed ratio when recovering large data setsAOFThe recovery rate is faster.
  2. Depending on the synchronization strategy,AOFThey tend to run slower thanRDB. In short, the efficiency of the synchronization policy per second is relatively high, and the efficiency of the synchronization disabled policy andRDBJust as efficient.

1.3 AOFThe configuration of the

Go to the redis configuration file /etc/redis/redis.conf

Enable AOF mode
appendonly yes
The AOF file is written every time a data change occurs
appendfsync always
This policy is the default policy of AOF.
appendfsync everysec
# Never synchronize. Efficient but data is not persisted
appendfsync no
Copy the code

2.RDBpersistence

2.1 Advantages of RDB

  1. Once done this way, your entire Redis database will contain only one file, which is perfect for file backups. For example, you might want to archive the last 24 hours of data every hour and the last 30 days of data every day. With this backup strategy, we can easily recover from catastrophic system failures.

  2. RDB is a great choice for disaster recovery. It is very easy to compress a single file and transfer it to another storage medium.

  3. Maximize performance. As for Redis server, the only thing it needs to do to start persistence is fork out the child process, and then the child process will do the work of persistence, so that the server process can not perform IO operations.

  4. Compared to AOF, RDB starts more efficiently if the data set is large.

2.2 Disadvantages of RDB

  1. RDB is not a good choice if you want to ensure high availability of data, i.e. avoid data loss as much as possible. If the system breaks down before scheduled persistence, data that has not been written to disk will be lost.

  2. The RDB often forks the child process to save the data set to the hard disk. When the data set is large, the fork process can be very time-consuming and may cause Redis to fail to respond to client requests for some milliseconds. If the data set is large and the CPU performance is not very good, this can last up to a second. AOF also requires forking, but you can adjust the frequency of rewriting log files to improve the durability of the data set.

2.3 CONFIGURING the RDB

Redis dumps a snapshot of the dataset into the dump. RDB file. In addition, the Redis server can also change the frequency of snapshot dump through configuration files

Dump the memory snapshot after 900 seconds (15 minutes) if at least one key has changed.
save 900 1
Dump the snapshot after 300 seconds (5 minutes) if at least 10 keys have changed.
save 300 10
Dump the memory snapshot after 60 seconds (1 minute) if at least 10000 keys have changed.
save 60, 10000

Copy the code

3. Hybrid mode

In version 4.0, mixed persistence is disabled by default. You can use the aof-use-rdb-preamble parameter to control mixed persistence. Yes indicates that mixed persistence is enabled, and no indicates that mixed persistence is disabled

Mixed persistence is also implemented through bgreWriteaof. The difference is that when mixed persistence is enabled, the child process forked out first writes the full copy of the shared memory to the AOF file in RDB mode, and then writes the increment command to rewrite the buffer to the FILE in AOF mode. After writing, the main process is notified to update the statistics. Replace old AOF files with new AOF files in RDB format and AOF format. Simply put: The first half of the new AOF file is full data in RDB format and the second half is incremental data in AOF format

When mixed persistence is enabled, the aOF file is still loaded first when redis is started. The aOF file may be loaded in the following two ways:

The aOF file starts with the RDB format, loading the RDB content before loading the rest of the AOF. The aOF file does not start in RDB format and loads the entire file directly in AOF format.

Reference: zhuanlan.zhihu.com/p/212419114

Reference: www.cnblogs.com/chenliangcl…