Redis AOF persistence principle

AOF persistent configuration

# Whether to open aof
appendonly yes

# File name
appendfilename "appendonly.aof"

# Sync mode
appendfsync everysec

# aof Whether to synchronize during rewriting
no-appendfsync-on-rewrite no

# Rewrite trigger configuration
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# What to do if there is an error when loading aof
aof-load-truncated yes # yes means that if there is a problem with the aof tail file, write a log record and continue execution. no means prompt to write and write after waiting for repair

# File rewrite strategy
aof-rewrite-incremental-fsync yes

 

 

• There are three modes of appendfsync synchronization mode. In general, everysec configuration is adopted , and a balanced choice is made in data and security, and the data loss is up to 1s.

  • always: synchronize every write command to aof immediately, which is slow but safe

  • everysec: Synchronize once every second, which is a compromise

  • no: Redis does not handle the processing, it is very fast, but it is also the least secure

     

• AOF view of the entire process can be roughly divided into two steps, step is to write real-time command (if it is appendfsync everysecconfigured, there 1s loss), the second step is a rewrite of the aof file.

  • step:

    • Command write = "Append to aof_buf = "Sync to aof disk by calling flushAppendOnlyFile function through time event

  • the reason:

    • Real-time writing to the disk will bring very high disk IO, affecting the overall performance

       

• Analysis of the efficiency and safety of AOF persistence

always: Each time event loop writes all the contents of the AOF_BUF buffer to the AOF file and synchronizes the AOF file. This is the safest way, but the disk operation and blocking delay are the IO expenses.
everysec: Synchronize once every second, the performance and security are relatively moderate, and it is also the method recommended by redis. If you encounter a physical server failure, it may cause the AOF record to be lost in the last second (may be a partial loss).
no: Redis does not directly call file synchronization, but hands it to the operating system for processing. The operating system can trigger synchronization according to buffer filling conditions/channel idle time, etc.; this is a common file operation method. The performance is better. When the physical server fails, the amount of data loss will be related to the OS configuration. The flushAppendOnlyFile call in no mode does not need to perform synchronization operations