Redis Persistence of

Redis There are two ways to persist ：RDB and AOF,redis The default is RDB The way .

RDB

In the default configuration ,Redis Save the memory database snapshot under the name dump.rdb In the binary file of .
You can configure persistence policies ：save N M, Give Way redis stay “N At least in seconds M A change ” Will trigger once rdb Persistence operation .
for example redis The default policies are ：

save 900 1   -- 900 At least one change in seconds 
save 300 10		-- 300 At least in seconds 10 A change 
save 60 10000	-- 60 At least in seconds 10000 A change 

You can also manually execute command generation RDB snapshot , Get into redis The client executes the command save or bgsave Can generate dump.rdb file ,
Every time the command is executed, all redis Memory snapshot to a new rdb In the document , And cover the original rdb Snapshot file .

bgsave Copy while writing （COW） Mechanism

Redis With the help of linux System copy on write （Copy-On-Write） technology , While taking a snapshot , You can still receive commands to process data . Simply speaking ,bgsave The thread is composed of the main thread fork Generated child thread , Can share all memory data of the main thread .bgsave After the thread runs , Start to read the memory data of the main thread , That is to say redis Memory data for , Write memory data to dump.rdb In file . here , If all the commands processed by the main thread are read operations , be bgsave Threads are not affected . If the main thread handles writes , A copy of the data operated by the command will be copied , Make a copy ,bgsave The thread will write this copy to dump.rdb In file , And in the process , The main thread can still execute commands .

save On bgsave contrast ：

Configure automatic generation rdb The file background uses bgsave The way .

RDB Advantages and disadvantages of this method ：
shortcoming ：

1. RDB Each persistence needs to write all memory data to the file , Then replace the original file , When there is a large amount of data in memory , Frequent snapshot generation will consume a lot of performance .
2. If the time interval of the policy setting that will generate the snapshot is large , It can lead to redis Data lost during downtime .
   advantage ：
   Should be dump.rdb Files are binary files , So when redis When the service crashes and recovers , Can quickly restore file data to memory .

AOF(Append-Only File)

To solve the problem RDB The problem of losing data , from 1.1 Version start ,redis Added a more reliable way ：AOF Persistence mode .
In the use of AOF When the way ,redis Every time you execute the modify data command , Will append the command to appendonly.aof In file （ Write... First os cache, And then through fsync Brush set ）.
You can use... By modifying the configuration file AOF：

# appendonly yes

redis When restarting , Will replay appendonly.aof Recover data with the command in .

AOF Three disk brushing strategies can be configured ：

appendfsync always： Every time I execute the write command, I will brush the disk , Very slow , It's also very safe .
appendfsync everysec： Swipe the disk once a second , Balance performance and safety .
appendfsync no： Hand over the disk brushing operation to the system , Soon , unsafe .

Recommended everysec, Under this strategy , At most 1 Second data .

AOF rewrite :
Should be appendonly.aof What is stored in the file is the execution command , So there will be a lot of useless commands , therefore ,redis New data will be generated periodically based on the latest memory data aof file .
The following two configurations can be controlled aop Frequency of file rewriting ：

 # auto‐aof‐rewrite‐min‐size 64mb：	-- aof The file has reached at least 64m Will trigger rewriting 
 # auto‐aof‐rewrite‐percentage 100：	--  It has increased since the last rewrite 100% Will trigger the rewrite again 

AOF Rewriting can also be triggered manually ：bgrewriteof
Be careful ,AOF rewrite redis Meeting fork Make a sub process to do ( And bgsave Command similar ), It won't be right redis There are too many normal command processing
influence

RDB On AOF contrast

All production environments can be enabled ,redis Start up if there is rdb Documents aof Documents are preferred aof File recovery data , because aof
Generally speaking, the data is more complete .

Redis 4.0 Mix persistence

restart Redis when , We seldom use RDB To restore memory state , Because a lot of data will be lost . We usually use AOF Log weight
discharge , But replay AOF Log performance is relative RDB It's a lot slower , In this way Redis When the examples are large , It costs a lot to start up
For a long time . Redis 4.0 To solve this problem , Brings a new persistence option —— Mix persistence .
Mixed persistence can be turned on through the following configuration ( Must be on first aof)：

 # aof‐use‐rdb‐preamble yes

If mixed persistence is turned on ,AOF When rewriting , It's no longer just about converting memory data to RESP Command write AOF file , But will rewrite the memory before this moment to do RDB Snapshot processing , And will RDB Snapshot content and incremental AOF There are commands for modifying memory data , All write new AOF file , The new document didn't start with appendonly.aof, Wait until the new AOF The document will be renamed , Cover the original AOF file , Finish the new and the old AOF Replacement of documents .
So in Redis When restarting , You can load RDB The content of , Then replay the increment AOF Log can completely replace the previous AOF Full file replay , So the restart efficiency has been greatly improved .
Mix persistence AOF The file structure is as follows ：

Redis Data backup strategy

1. Write crontab Scheduled scripts , Every hour copy One copy rdb or aof Backup to a directory , Just keep the latest 48
   Hours of backup .
2. Keep a copy of the data of the day every day and back it up to a directory , You can keep the latest 1 Months of backup .
3. Every time copy Back up , I deleted the old backup .
4. Copy the backup on the current machine to other machines every night , In case of machine damage .