Shulou(Shulou.com)06/01 Report--

Redis provides different levels of persistence:

RDB persistence allows snapshot storage of your data at specified intervals.

AOF persistence method records each write operation to the server, when the server restarts, these commands will be re-executed to restore the original data. AOF command to save each write operation to the end of the file with redis protocol. Redis can also rewrite the AOF file in the background, so that the size of the AOF file is not too large.

If you only want your data to exist while the server is running, you don't have to use any persistence.

You can also turn on both persistence methods. In this case, when redis restarts, the AOF file will be loaded first to recover the original data, because in general, the dataset saved by the AOF file is more complete than the dataset saved by the RDB file.

The most important thing is to understand the difference between RDB and AOF persistence. Let's start with RDB persistence:

Advantages of RDB

RDB is a very compact file, which saves the dataset at a certain point in time, which is very suitable for the backup of dataset. For example, you can save the data in the past 24 hours in every hour report, and save the data in the past 30 days every day, so that you can restore to different versions of the dataset according to your needs even if something goes wrong.

RDB is a compact single file that can be easily transferred to another remote data center or Amazon's S3 (possibly encrypted), making it ideal for disaster recovery.

When RDB saves the RDB file, the only thing the parent process needs to do is to fork a child process, and all the subsequent work is done by the child process, and the parent process does not need to do other IO operations, so RDB persistence can maximize the performance of redis.

Compared with AOF, RDB is faster when recovering large data sets.

Shortcomings of RDB

If you want to lose the least amount of data if redis stops working accidentally (such as a power outage), then RDB is not for you. Although you can configure different save time points (for example, every 5 minutes and 100 writes to the dataset), it is a heavy task for Redis to save the entire dataset completely, and you usually do a complete save every 5 minutes or more. In case of an accidental downtime in Redis, you may lose a few minutes of data.

RDB needs frequent fork subprocesses to save the dataset to the hard disk. When the dataset is large, the fork process is very time-consuming, which may cause Redis to be unable to respond to client requests in milliseconds. If the dataset is large and the CPU performance is not very good, this will last for 1 second, and AOF also requires fork, but you can adjust the frequency of rewriting log files to improve the durability of the dataset.

Advantages of AOF

Using AOF will make your Redis more durable: you can use different fsync strategies: no fsync, fsync per second, fsync every time you write. Using the default per second fsync policy, Redis still performs well (fsync is processed by background threads, and the main thread will try its best to handle client requests). In the event of a failure, you will lose up to 1 second of data.

The AOF file is an append-only log file, so you don't need to write to seek, even if you don't execute a complete write command for some reason (disk space is full, downtime during writing, etc.), you can also use the redis-check-aof tool to fix these problems.

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.

Shortcomings of AOF

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.

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.