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

This article introduces how AOF and RBD are used in redis. The content is very detailed. Interested friends can use it for reference. I hope it will be helpful to you.

Typical redis application scenarios:

Rdb file

The Rdb file is the equivalent of mysqldump in mysql backing up all the data in memory to the local disk.

RDB (Redis DataBase): time-based snapshot, which only retains the latest snapshot by default. It is characterized by its high speed of holding rows, and the disadvantage is that it may lose data that has not been snapped from the last snapshot to the current point in time.

In the specific process of RDB implementation, Redis first fork a child process from the main process. Using the write-time copy mechanism, the sub-process saves the data in memory as a temporary file, such as dump.rdb.temp, replaces the last saved RDB file after the data is saved, and then closes the child process, so that the data saved every time you take a RDB snapshot is complete. Because there may be problems such as a sudden power outage when directly replacing RDB files, which leads to the sudden shutdown and data loss of RDB files before they are completely saved, you can manually back up each generated RDB file process, so as to maximize the preservation of historical data.

Pros and cons of the RDB model:

Advantages:

-RDB snapshots save data at a certain point in time. You can use scripts to execute bgsave (non-blocking) or save (blocking) commands to customize point-in-time backups. You can keep multiple backups and restore to different time-point versions when problems occur.

The performance of IO can be maximized, because the only thing the parent process needs to do when saving the RDB file is to fork a child process, and then the parent process will have this child process operation. The parent process does not need any IO operation. The recovery speed of RDB in a large amount of data, such as several gigabytes of data, is faster than that of AOF.

Disadvantages:

-data cannot be saved from time to time, and memory data from the last RDB backup to the current memory will be lost.

-when the amount of data is very large, it takes some time to fork from the parent process, which may be milliseconds or seconds or minutes, depending on the disk IO performance.

AOF file

The AOF file is similar to the binary log in mysql. If redis goes down during the period from the last full backup to the next full backup, the data generated during this period will be lost, and the AOF file can save the data during this period.

Note: when the AOF function is enabled, each restart of redis will load the AOF file, not the RDB file. When the AOF function is turned off, even if there is an AOF file, restarting redis will not load the file.'

The operations are added to the specified log files in turn according to the operation order, which is characterized by relatively high data security, but the disadvantage is that all operations are recorded even if some operations are repeated.

AOF uses the copy-on-write mechanism like RDB. AOF defaults to fsync once per second, and the commands to be executed are saved to the AOF file, so that even if the redis server fails, the data within 1 second will be lost at most. You can also set a different fsync policy, or set fsync to execute each time the command is executed, and fsync will execute the thread in the background. So the main thread can continue to process the user's normal request without being affected by the IO written to the AOF file

Pros and cons of the AOF model:

The file size of AOF is larger than that of RDB format.

According to the fsync policy used (fsync is to synchronize all modified files in memory with redis to the storage device)

The default is appendfsync everysec, which means fsync is executed every second.

The configurations related to aof are as follows:

# # APPEND ONLY MODE # #

# whether to enable AOF. Disable it by default (no)

Appendonly yes

# specify AOF file name

Appendfilename appendonly.aof

# Redis supports three different swipe modes:

# appendfsync always # force to write to disk every time you receive a write command, which is the most guaranteed and complete persistence, but it is also the slowest, and is generally not recommended.

Appendfsync everysec # forces writing to disk once per second, making a good tradeoff between performance and persistence, and is the recommended way.

# appendfsync no # relies entirely on OS writes, usually about once in 30 seconds. It has the best performance but the least guarantee of persistence, so it is not recommended.

# during log rewriting, do not append the command, but just put it in the buffer to avoid conflict with the command appending on the DISK IO.

# set to yes means that new writes are not fsync during rewrite and are temporarily stored in memory until the rewrite is completed. Default is no.

No-appendfsync-on-rewrite no

# when the current AOF file size is twice the size of the AOF file obtained from the last log rewrite, a new log rewrite process is automatically started.

Auto-aof-rewrite-percentage 100

# the minimum value for the current AOF file to start a new log rewriting process to avoid frequent rewriting due to small file size when Reids is just started.

Auto-aof-rewrite-min-size 64mb

About redis's AOF flush mode and log rewriting:

Because write operations are usually buffered, it is possible that AOF operations are not written to the hard disk and can generally be forced to be output to the hard disk through fsync (). The frequency of fsync () can be specified by the flush policy in the configuration file, and you can choose to force fsync or fsync to run at least once per second for each event loop write operation.

When the rewrite child process starts, the commands received by the parent process are added to the aof_rewrite_buf_blocks, and when the rewrite succeeds, these commands are added to the new file. In the rewrite process, the original AOF can also choose whether to continue to add, due to performance problems, in the rewrite process, if fsync () continues to execute, it will cause IO performance damage and affect Redis performance. Therefore, fsync () to the old AOF file is generally prohibited during rewrite. This policy can be modified in the configuration file.

So much for sharing the usage of AOF and RBD in redis. I hope the above content can be of some help 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.