Shulou(Shulou.com)05/31 Report--

This article introduces what aof and rdb are in redis and what are the differences between them. The content is very detailed. Interested friends can use it for reference. I hope it will be helpful to you.

Aof and rdb persistence of redis

1.RDB AOF distinction

RDB persistence means that the snapshot of the dataset in memory is written to disk within a specified time interval. Fork a child process first writes the dataset to a temporary file. After the write is successful, the previous file is replaced and stored with binary compression.

Specific operation: traversing the hash table, using copy on write, save the entire db dump.

The save, shutdown, slave commands trigger this operation.

Features: the granularity is relatively large, if the crash before save, shutdown, slave, then the middle operation can not be restored.

AOF persistence records every write and delete operation processed by the server in the form of log, query operation is not recorded, it is recorded in the form of text, and you can open the file to see the detailed operation record. Redis can also rewrite (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 dataset state. Redis can also use both AOF persistence and RDB persistence. In this case, when Redis restarts, it gives priority to using the AOF file to restore the dataset because the dataset saved by the AOF file is usually more complete than the dataset saved by the RDB file. You can even turn off persistence so that the data exists only while the server is running.

Features: small granularity, after crash, there is no way to recover operations that have not had time to log before crash.

The choice standard is to see whether the system is willing to sacrifice some performance for higher cache consistency (aof), or is willing to write frequently, do not enable backup in exchange for higher performance, and then do a backup (rdb) when you run save manually. Rdb is even more eventually consistent.

Advantages and disadvantages of 2.AOF RDB

AOF:

Pros: using AOF persistence makes Redis very durable (much more durable): you can set different fsync policies, such as no fsync, fsync per second, or fsync each time a write command is executed. AOF's default policy is to fsync once per second, under this configuration, Redis can still maintain good performance, and even if a failure occurs, it will only lose data for up to one second (fsync executes in the background thread, so the main thread can continue to work hard on command requests). The AOF file is an append-only log file (append only log), so writing to the AOF file does not require seek, and the redis-check-aof tool can easily fix this problem even if the log contains commands that are not fully written for some reason (such as disk full at write time, write outage, etc.).

Redis can automatically rewrite AOF in the background when the AOF file becomes too large: the new AOF file after rewriting contains the minimum set of commands needed to recover the current dataset. The entire rewrite operation is perfectly safe because Redis continues to append commands to existing AOF files during the creation of new AOF files, and existing AOF files will not be lost even if downtime occurs during rewriting. 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. The AOF file saves all writes to the database in an orderly manner, which are saved in the format of the Redis protocol, so the contents of the AOF file are easy to read and parse. Exporting (export) the AOF file is also very simple: for example, if you accidentally execute the FLUSHALL command, but as long as the AOF file is not rewritten, simply stop the server, remove the FLUSHALL command at the end of the AOF file, and restart Redis, and you can restore the dataset to the state it was before the FLUSHALL execution.

Disadvantages:

For the same dataset, the volume of the AOF file is usually larger than that of the RDB file. Depending on the fsync strategy used, AOF may be slower than RDB. In general, the performance of fsync per second is still very high, and turning off fsync can make AOF as fast as RDB, even under heavy loads. However, RDB can provide a more guaranteed maximum latency (latency) when dealing with large write loads. AOF has had such bug in the past: due to individual commands, when the AOF file is reloaded, the dataset cannot be restored to what it was when it was saved. (for example, the blocking command BRPOPLPUSH has caused such a bug. Tests are added to the test suite: they automatically generate random, complex data sets and make sure everything is all right by reloading the data Although this kind of bug is not common in AOF files, it is almost impossible for RDB to have this kind of bug by comparison.

Advantages of RDB:

RDB is a very compact file that holds the dataset of Redis at some point in time. This kind of file is ideal for backup: for example, you can back up RDB files every hour for the last 24 hours, and also back up a RDB file every day of each month. In this way, even if you encounter problems, you can restore the dataset to a different version at any time. RDB is ideal for disaster recovery (disaster recovery): it has only one file and the content is so compact that it can be transferred (after encryption) to another data center, 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 rest of the save work, and the parent process does not have to perform any disk I / O operations. RDB recovers large datasets faster than AOF does.

Disadvantages:

If you need to avoid losing data in the event of a server failure, RDB is not for you. Although Redis allows you to set different save points (save point) to control how often the RDB file is saved, because the RDB file needs to save the state of the entire dataset, it is not an easy operation. So you may save the RDB file at least once in 5 minutes. In this case, in the event of a downtime, you may lose data for several minutes. Each time the RDB is saved, the Redis needs to fork () a child process, and the child process does the actual persistence work. When the dataset is large, fork () can be very time-consuming, causing the server to stop processing the client in so-and-so milliseconds; if the dataset is very large and CPU time is very tight, the stop time may even be as long as a full second. Although AOF rewriting also requires fork (), there is no loss of data durability no matter how long the execution interval of AOF rewriting is.

What is aof and rdb in redis and what is the difference between them is shared here. I hope the above content can be helpful to you and learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.