Redis learning notes - AOF of persistence mechanism

AOF（append only file） Persistence ： Each write is logged as a separate log , Reexecute on reboot AOF The command in the file restores the data .AOF Its main function is to solve the real-time problem of data persistence , So far Redis The mainstream way of persistence .

Turn on AOF Function requires configuration ：appendonly yes,AOF File name passed appendfilename Configuration settings , The default filename is appendonly.aof. Save path is the same as RDB Consistent persistence , adopt dir Configuration assignment .

appendonly The default is no, Need to change to yes

# By default Redis asynchronously dumps the dataset on disk. This mode is
# good enough in many applications, but an issue with the Redis process or
# a power outage may result into a few minutes of writes lost (depending on
# the configured save points).
#
# The Append Only File is an alternative persistence mode that provides
# much better durability. For instance using the default data fsync policy
# (see later in the config file) Redis can lose just one second of writes in a
# dramatic event like a server power outage, or a single write if something
# wrong with the Redis process itself happens, but the operating system is
# still running correctly.
#
# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check http://redis.io/topics/persistence for more information.

appendonly no

file name , The default is appendonly.aof

# The name of the append only file (default: "appendonly.aof")

appendfilename "appendonly.aof"

AOF The workflow operation of ： Command write （append）、 File synchronization （sync）、 File rewriting （rewrite）、 Restart loading （load）, Here's the picture

1. All write commands are appended to aof_buf（ buffer ） in
2. AOF The buffer synchronizes the hard disk according to the corresponding policy
3. With AOF The files are getting bigger , It needs to be done regularly AOF File rewriting , Achieve the purpose of compression
4. When Redis When the server restarts , Can be loaded AOF File for data recovery .

Command write

AOF The content written by the command is directly in the format of text protocol , That is RESP,Redis Serialization protocol

for example set hello world This command , stay AOF The buffer will be appended with the following text

*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n

AOF Will append the command to aof_buf The benefits of ：Redis Responding to commands with a single thread , If you write every time AOF File commands are all appended directly to the hard disk , The performance depends on the current hard disk load . Write buffer first aof_buf in , There is another benefit ,Redis Can provide a variety of buffer synchronization hard disk strategy , Balance performance and security

File synchronization

Redis Provides a variety of AOF Buffer synchronization file policy , By the parameter appendfsync control

# The fsync() call tells the Operating System to actually write data on disk
# instead of waiting for more data in the output buffer. Some OS will really flush
# data on disk, some other OS will just try to do it ASAP.
#
# Redis supports three different modes:
#
# no: don't fsync, just let the OS flush the data when it wants. Faster.
# always: fsync after every write to the append only log. Slow, Safest.
# everysec: fsync only one time every second. Compromise.
#
# The default is "everysec", as that's usually the right compromise between
# speed and data safety. It's up to you to understand if you can relax this to
# "no" that will let the operating system flush the output buffer when
# it wants, for better performances (but if you can live with the idea of
# some data loss consider the default persistence mode that's snapshotting),
# or on the contrary, use "always" that's very slow but a bit safer than
# everysec.
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# If unsure, use "everysec".

# appendfsync always
appendfsync everysec
# appendfsync no

system call write and fsync explain

• write Operation will trigger delay write （delayed write） Mechanism .Linux Provide page buffer in kernel to improve hard disk IO performance .write The operation directly returns... After writing to the system buffer . Synchronous hard disk operation depends on system scheduling mechanism , for example ： Buffer page space is full or reaches a specific time period . Before synchronizing files , If the system fails at this time , Data in the buffer will be lost
• fsync For single file operations （ such as AOF file ）, Do force hard disk synchronization ,fsync Will block until writing to the hard disk is complete and return to , Data persistence is guaranteed
• Configure to always when , Synchronize every write AOF file , In a normal SATA On hard disk ,Redis Only about a few hundred TPS write in , Obviously with Redis High performance is the opposite , Configuration not recommended
• Configure to no, Due to every synchronization of the operating system AOF Uncontrollable period of file , And it will increase the amount of data in each synchronization of the hard disk , While improving performance , But data security cannot be guaranteed
• Configure to everysec, Is the recommended synchronization strategy , Is also the default configuration , Balance performance and data security . In theory, it can only be lost when the system suddenly goes down 1 Second data

Rewrite mechanism

As commands are written AOF, The file will get bigger and bigger , To solve this problem ,Redis introduce AOF Rewrite mechanism to compress file volume .AOF File rewriting is to Redis In process data is converted to write command and synchronized to new AOF Documentation process

• The rewritten AOF The reason why the file gets smaller ：
• Data that has timed out in the process is no longer written to the file
• old AOF File contains invalid command , Such as del key1、hdel key2、srem keys、set a 111、set a 222 etc. . Rewriting is directly generated using in-process data , So new AOF Write command to keep only the final data in the file
• Multiple write commands can be combined into one , Such as ：lpush list a、lpush list b、lpush list c Can be converted to ：lpush list a b c. In order to prevent client buffer overflow caused by too large a single command , about list、set、hash、zset Equal type operation , With 64 Divided into multiple elements

AOF Rewriting reduces file footprint , besides , Another purpose is ： Smaller AOF Files can be made faster by Redis load

AOF The rewriting process can be triggered manually and automatically

Manual trigger ： Call directly bgrewriteaof command

Automatic triggering ： according to auto-aof-rewrite-min-size and auto-aof-rewrite-percentage Parameter determination of automatic trigger time

# Automatic rewrite of the append only file.
# Redis is able to automatically rewrite the log file implicitly calling
# BGREWRITEAOF when the AOF log size grows by the specified percentage.
#
# This is how it works: Redis remembers the size of the AOF file after the
# latest rewrite (if no rewrite has happened since the restart, the size of
# the AOF at startup is used).
#
# This base size is compared to the current size. If the current size is
# bigger than the specified percentage, the rewrite is triggered. Also
# you need to specify a minimal size for the AOF file to be rewritten, this
# is useful to avoid rewriting the AOF file even if the percentage increase
# is reached but it is still pretty small.
#
# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

auto-aof-rewrite-min-size： Said to run AOF Minimum file size on rewrite , The default is 64MB

auto-aof-rewrite-percentage： On behalf of the current AOF File space （aof_current_size） And after the last rewrite AOF File space （aof_base_size） The ratio of the

Automatic trigger time =aof_current_size>auto-aof-rewrite-min-size&&（aof_current_size-aof_base_size）/aof_base_size>=auto-aof-rewrite-percentage

among aof_current_size and aof_base_size Can be in info Persistence See... In statistics

AOF The rewrite operation flow is shown in the following figure

1. perform AOF Rewrite request

2. Parent process execution fork Create child process , The cost is equal to bgsave The process

3.1 The main process fork After the operation is completed , Continue to respond to other orders . All modification commands are still written AOF Buffer and according to appendfsync Policy synced to hard disk , Keep the original AOF Mechanism correctness

3.2 because fork Operations use write time replication technology , Child processes can only share fork Memory data during operation . Because the parent process is still responding to commands ,Redis Use “AOF Rewrite buffer ” Save this new data , Prevent new AOF This data is lost during file generation

4 Sub process according to memory snapshot , Write to the new... According to the command merge rule AOF file . The amount of data written to the hard disk in batches is configured by aof-rewrite-incremental-fsync control , The default is 32MB, Prevent the hard disk from blocking due to too much data in a single brush

5.1 new AOF When the file is written , The child process signals the parent process , Parent process update statistics , Specific view info persistence Under the aof_* Relevant statistics

5.2 The parent process put AOF The data in the rewrite buffer is written to the new AOF file

5.3 Using the new AOF File replace old file , complete AOF rewrite

Restart loading

AOF and RDB Files can be used for data recovery when the server restarts , The figure below shows Redis Persistent file loading process

File check

Load corrupted AOF File will refuse to start , And print the following log ：

# Bad file format reading the append only file: make a backup of your AOF file,then use ./redis-check-aof --fix 

For malformed AOF file , Backup first , Then use redis-check-aof–fix Command to repair , Use after repair diff-u Differences in comparative data , Find the missing data , Some can be modified and completed manually .

AOF The end of the file may be incomplete , For example, the sudden power failure of the machine leads to AOF Incomplete writing of tail file command .Redis For us aof-load-truncated Configure to be compatible with this situation , Default on . load AOF when , When this problem is encountered, it will ignore and continue to start , At the same time, print the following warning log ：

# !!! Warning: short read while loading the AOF file !!!
# !!! Truncating the AOF at offset 397856725 !!!
# AOF loaded anyway because aof-load-truncated is enabled

This is in the configuration file aof-load-truncated The default configuration and official detailed documentation

# An AOF file may be found to be truncated at the end during the Redis
# startup process, when the AOF data gets loaded back into memory.
# This may happen when the system where Redis is running
# crashes, especially when an ext4 filesystem is mounted without the
# data=ordered option (however this can't happen when Redis itself
# crashes or aborts but the operating system still works correctly).
#
# Redis can either exit with an error when this happens, or load as much
# data as possible (the default now) and start if the AOF file is found
# to be truncated at the end. The following option controls this behavior.
#
# If aof-load-truncated is set to yes, a truncated AOF file is loaded and
# the Redis server starts emitting a log to inform the user of the event.
# Otherwise if the option is set to no, the server aborts with an error
# and refuses to start. When the option is set to no, the user requires
# to fix the AOF file using the "redis-check-aof" utility before to restart
# the server.
#
# Note that if the AOF file will be found to be corrupted in the middle
# the server will still exit with an error. This option only applies when
# Redis will try to read more data from the AOF file but not enough bytes
# will be found.
aof-load-truncated yes

AOF Add blocking

When open AOF Persistence , The common strategy of synchronizing the hard disk is everysec, Used to balance performance and data security . For this way ,Redis Use another thread to execute... Per second fsync Sync hard disk . When the system hard disk resources are busy , Can cause Redis Main thread blocking . As shown in the figure below ：

1. The main thread is responsible for writing AOF buffer

2. AOF The thread is responsible for performing synchronous disk operations once a second , And record the last synchronization time

3. The main thread is responsible for comparing the last time AOF Synchronization time ：

   • If the last synchronization success time is in 2 Seconds , The main thread directly returns
   • If the time from the last successful synchronization exceeds 2 second , The main thread will block , Until the synchronization is complete

AOF Blocking problem location :

1. happen AOF Blocking time ,Redis Output the following log , Used to record AOF fsync Blocking causes a delay Redis The act of serving ：

Asynchronous AOF fsync is taking too long (disk is busy). Writing the AOF buffer
without waiting for fsync to complete, this may slow down Redis

2. Whenever it happens AOF When an additional blocking event occurs , stay info Persistence In statistical work, ,aof_delayed_fsync The indicators will add up , Check this indicator to facilitate positioning AOF Blocking problem

3. AOF Synchronization allows up to 2 Second delay , When the delay occurs, it indicates that the hard disk has a high load problem , You can use monitoring tools such as iotop, Positioning consumes hard disk IO Process of resources