An article thorough understanding Redis persistence: RDB and AOF

Why persist?

Redis operations on the data are based on memory, when faced with a process exits, server downtime and other unforeseen circumstances, if there is no persistence mechanism, then the Redis data will be lost can not be recovered. With persistence mechanism, persistence before you can use Redis restart when the next file for data recovery. Redis persistence mechanism to understand and grasp, for the daily operation and maintenance and development of Redis is very helpful, also in an interview frequently asked manufacturers of knowledge. Redis supports two persistence mechanisms:

1. RDB: a snapshot of the current data stored on the hard disk.
2. AOF: each recording operation on the data to the hard disk.

Next, we learn more about these two persistence mechanisms.

RDB endurance of

RDB (Redis DataBase) is the current Redis persistence in all of the data generated snapshots stored on the hard disk. RDB persistence can be triggered manually or automatically triggered.

Manual trigger

saveAnd bgsavecommands can be triggered manually RDB persistence.

save command

Execute savecommand manually triggered RDB persistence, but savethe command will block Redis service until RDB persistence to complete. When Redis service to store large amounts of data, it will cause obstruction long time, it is not recommended.

> save
OK

After the execution, Redis recorded in the log:

 * DB saved on disk

bgsave command

Execute bgsavecommand also manually trigger RDB persistence, and savecommands are different: Redis services in general will not block. Redis process will execute fork operation to create a child process, RDB persistent responsible for the child, does not block the Redis service process. Redis service blocking occurs only at the stage fork, in general, a very short time.

> bgsave
Background saving started

After the execution, Redis recorded in the log:

 * Background saving started by pid 2645
 * DB saved on disk
 * RDB: 0 MB of memory used by copy-on-write
 * Background saving terminated with success

bgsaveFIG commands specific process is as follows:

1. Execute bgsavecommands, Redis process to determine whether there is currently RDB or AOF sub-executing thread, if there is a direct end.
2. Redis process execution fork operation to create a child thread, Redis process will be blocked during the fork operation.
3. After Redis process fork is complete, bgsavethe command is over, since Redis process is not blocked, you can respond to other commands.
4. According to the child process generates a memory snapshot file Redis process and replace the original file RDB.
5. Redis notification process child process has been completed by semaphore.

Automatically trigger

In addition to performing the above command manually triggered outside, inside Redis can be triggered automatically RDB persistence. Automatically triggered persistent RDB are based bgsaveapproach, reduce congestion Redis process. So, under what scenario will automatically trigger it?

1. Save the configuration settings in the configuration file, such as sava m n, when it has been modified indicates n times m data seconds, automatically trigger bgsaveoperation.
2. When the total amount of replication from the node doing, the master node will automatically perform bgsavethe operation, and transmits the generated file to the node RDB.
3. Execute debug reloadcommand, it will automatically trigger bgsaveoperation.
4. Execute shutdowncommand, if not open AOF persistence will automatically trigger bgsaveoperation.

RDB advantage

RDB is a compact binary file compressed file, Redis is a snapshot of all the data at some point in time. So use RDB to recover data much faster than fast AOF, ideal for backup, full volume copy, disaster recovery scenario.

RDB shortcomings

Every time bgsavethe operation must perform regular fork operation to create a child belonging to heavyweight operations, frequently performed high cost, so I can not do real-time persistence, persistence or second grade.

In addition, because of the continuous iteration Redis version, there are different formats of RDB version, it is possible to lower version of RDB format is not compatible versions of high RDB file problems.

AOF persistence

AOF (Append Only File) persistence is added to each write command written to the log, when you need to recover data re-execute the AOF file command on it. AOF solve the real-time data persistence, it is currently the mainstream of Redis persistence mode.

AOF persistent flow

FIG AOF process is as follows:

1. Append command (append): all write commands are added to the AOF buffer (aof_buf) in.
2. File synchronization (sync): Depending on the policy cache is synchronized to AOF AOF file.
3. File Rewrite (rewrite): AOF files regularly rewritten to achieve the purpose of compression.
4. Data is loaded (load): When you need to restore data, re-execute the commands in the file AOF.

File synchronization strategy

AOF persistent file synchronization process has the following strategies:

1. Always : Each write buffer must be synchronized to the AOF file, hard disk operation is relatively slow, limiting the Redis high concurrency, the configuration is not recommended.
2. NO : not performed after each write buffer, the synchronization file to AOF operation by the operating system is responsible for each cycle of the synchronization file AOF uncontrollable, and increases the amount of data per disk synchronization.
3. eversec : after each write buffer, synchronization once per second by the dedicated thread, so that both performance and data security. Is recommended synchronization strategy is the default strategy.

Trigger overwriting files

AOF persistent file rewrite process can be triggered manually or automatically triggered.

1. Manual trigger: Use the bgrewriteaofcommand.
2. Auto: determining timing triggered automatically arranged according to auto-aof-rewrite-min-size and auto-aof-rewrite-percentage. auto-aof-rewrite-min-size represents a minimum value when rewriting operation AOF file size, default is 64MB; auto-aof-rewrite-percentage represents the ratio of AOF after a rewrite of the current file size and the file size of the smallest AOF value, default is 100. While only the first two will be triggered automatically overwriting files exceeded.

AOF persistence configuration

After AOF persistence of specific processes have to understand, we look at how to configure the AOF. AOF persistence is not turned on by default, you need to modify the configuration file, such as:

# appendonly改为yes，开启AOF
appendonly yes
# AOF文件的名字
appendfilename "appendonly.aof"
# AOF文件的写入方式
# everysec 每个一秒将缓存区内容写入文件 默认开启的写入方式
appendfsync everysec
# 运行AOF重写时AOF文件大小的增长率的最小值
auto-aof-rewrite-percentage 100
# 运行AOF重写时文件大小的最小值
auto-aof-rewrite-min-size 64mb