This is the 18th day of my participation in the August Genwen Challenge.More challenges in August

AOF rewrite

AOF persistence means that Redis continuously records write commands into AOF files. As Redis continues, AOF files will become larger and larger. Larger files will occupy more server memory and require longer AOF recovery time. To solve this problem, Redis has added a rewriting mechanism, which starts the content compression of AOF files when the size of AOF files exceeds a set threshold, keeping only the smallest instruction set that can recover data. The merge directive can be overridden using the bgrewriteaof command.

AOF file rewriting is not to rearrange the original file, but to directly read the server’s existing key and value pairs, and then replace the previous multiple commands that recorded this key and value pair with a command, and generate a new file to replace the original AOF file.

The AOF file rewrite trigger mechanism is as follows: use the auto-aof-rewrite-percentage command in the redis.conf configuration file. The default value is 100 and the auto-aof-rewrite-min-size command to trigger the AOF file rewrite. The default configuration is triggered when the AOF file is twice the size of the last rewrite and the file is larger than 64MB.

The AOF override occurs in the child process and the AOF override buffer is set. This buffer is used after the child process is created. When the Redis server executes a write command, it sends the write command to the AOF override buffer as well. When the child process completes the AOF rewrite, it sends a signal to the parent process, which calls a function to write the contents of the AOF rewrite buffer to the new AOF file. This minimizes the impact of AOF rewriting on the server.

AOF the pros and cons

Advantages:

(1) The AOF persistent method provides multiple synchronization frequencies. Even if the default synchronization frequency is used once per second, Redis will lose at most 1 second of data.

AOF files are constructed with Redis command appending, so it is easy to modify AOF files with redis-check-aOF even if Redis can only write command fragments to AOF files.

③, **AOF file format is more readable, which also provides users with more flexible processing mode. ** If we accidentally use the FLUSHALL command, for example, we can manually flush out the final FLUSHALL command before rewriting and then use AOF to restore the data.

Disadvantages:

For Redis with the same data, AOF files are usually larger than RDF files.

② Although AOF provides a variety of synchronization frequencies, by default, the frequency of synchronization per second also provides high performance. However, when Redis is under high load, RDB provides better performance guarantee than AOF.

(3) RDB uses snapshots to persist the entire Redis data, while AOF simply appends each command to an AOF file. Therefore, RDB is theoretically more robust than AOF. The official documentation also points out that AOF does have some bugs that do not exist in the RDB.

So how do we choose between AOF and RDB persistence?

If you can tolerate the loss of data for a short period of time, there is no doubt that RDB is best. Periodic SNAPSHOTS are very convenient for database backup, and RDB can restore data sets faster than AOF. And using RDB can also avoid some hidden AOF bugs; Otherwise, rewrite using AOF. In this case, when Redis restarts, AOF files will be loaded first to recover the original data, because in general, AOF files hold more complete data sets than RDB files. Redis may officially integrate the two persistence methods into one persistence model.

Rdb-aof hybrid persistence

After Redis4.0, the rDB-AOF hybrid persistence mode is added to the RDB and AOF hybrid persistence mode.

This approach combines the advantages of RDB and AOF for fast loading without losing too much data.