Redis Persistence strategy grooming and policy adjustment record in master-slave environment

Redis is a memory database in which all of its data is stored in memory and then periodically asynchronously saved to disk (this is known as "semi-persistent mode"), and each data change can be written to a append only File (AOF) ( This is called "Full persistence mode").
Redis provides two different levels of persistence: One is the default Rdb (filesnapshotting snapshot) persistence, and the other is aof persistence , which can save the state of the in-memory database to disk in two ways. But the principle is very different, the difference is obvious!

1.RDB persistence can generate a point-in-time snapshot of a dataset (Point-in-time snapshot) within a specified time interval. RBD is the recording of operations over a period of time, and the general configuration is persistent over many times over a period of time.
The default Redis is a snapshot of the data persisted to the disk (a binary file, Dump.rdb, this file name can be specified), the format in the configuration file is: Save N m means that within N seconds, redis occurs at least m modified Redis snapshot to disk. Of course, you can also manually perform a Save or Bgsave (asynchronous) snapshot.
working principle:
When Redis needs to be persisted, Redis will fork a child process, and the child process will write the data to a temporary RDB file on disk, and when the child process finishes writing the temporary file, the original RDB is replaced, so the advantage is that it can be copy-on-write ( Write-time replication technology )

The 2.AOF persistence records all the write commands that the server performs and restores the dataset by re-executing the commands when the server starts. AoF can be persisted for each operation.
The commands in the AoF file are all saved in the Redis protocol format, and the new command is appended to the end of the file. Redis can also override the AoF file in the background (rewrite) so that the volume of the aof file does not exceed the actual size required to save the dataset State. Redis can also use both aof persistence and RDB persistence. In this case, when the Redis restarts, it takes precedence over the aof file to restore the dataset because the AoF file saves a dataset that is typically more complete than the data set saved by the Rdb file. You can even turn off the persistence feature so that the data exists only when the server is running.

The Rdb method is the most important drawback when Redis is dead, and the most recent data is lost (the amount of data lost depends on the configuration of your save policy), so this is its biggest disadvantage, and when the volume of business is large, the lost data is many.
the Append-only method can do all the data without loss, but the performance of Redis will be worse. AoF will be able to achieve full-length persistence, only need to open in the configuration file (default is no), appendonly Yes open aof, Redis every time you execute a modified data command, will add it to the AoF file, when the Redis restart, The aof file will be read for "replay" to revert to the last moment before Redis shutdown.

log rewriting (rewrite) as the execution of the modified data aof file becomes larger, many of which record the change of a key . So Redis has a more interesting feature: rebuilding the aof file in the background without affecting the client side operation. Executing the bgrewriteaof command at any time will write commands for the shortest sequence in the current memory to disk, which can completely build the current data situation without any extraneous changes (such as state changes, counter changes, etc.) and the size of the aof file. so when using AOF, Redis recommends using bgrewriteaof at the same time. The AOF rewrite, like the RDB snapshot, cleverly leverages the write-time replication mechanism.

To compress aof persistent files, Redis provides the bgrewriteaof command.
When this command is received, Redis will use a snapshot-like method to save the data in memory to a temporary file in the form of a command, and finally replace the original file to achieve control over the growth of the aof file.
Because it is the process of simulating a snapshot, the old aof file is not read while overriding the AoF file, but instead the entire in-memory database content is rewritten with a command to a new aof file.

aof file refresh in three ways, refer to configuration Parameters Appendfsync:
     appendfsync always: each commit a modification command calls Fsync flush to the aof file, very, very slow, but also very secure;
     appendfsync everysec: calls Fsync to aof files every second, and soon, but may lose less than one second of data;
    appendfsync No: The relies on OS refresh, Redis does not actively refresh aof, this is the fastest, but the security is poor. The default and recommended refresh per second, so that both speed and security are done.

redis The default persistence is an RDB, and data is written to the dump file. If you want to enable AOF persistence, configure it in the redis.conf file as follows:
    appendonly Yes         #启用AOF持久化方式
    appendfilename "appendonly.aof"       #AOF文件的名称, default is appendonly.aof
    # Appendfsync always         #每次收到写命令就立即强制写入磁盘, is the most guaranteed full persistence, but the speed is also the slowest, generally not recommended to use.
   appendfsync everysec         #每秒钟强制写入磁盘一次, A good compromise between performance and persistence, this fsync strategy is a recommended way to take into account speed and security.
   # appendfsync no         #完全依赖OS的写入, Typically 30 seconds or so, performance is best but persistence is the least guaranteed and not recommended.

Redis can no longer load the faulty AOF file due to system-based aof corruption, which is fixed in the following steps:
1) First do a aof file backup, copy to other places;
2) Repair the original aof file, execute the command redis-check-aof–fix;
3) The Diff–u command can be used to see where the files are inconsistent before and after the repair;
4) Restart the Redis service.

How the LOG rewrite works:
Also used Copy-on-write: First Redis will fork a child process, the child process writes the latest aof to a temporary file, the parent process increments the most recent execution in memory to write (at this point still write to the old aof,rewrite if the failure is also safe) When the child process finishes rewrite the temporary file, the parent process receives a signal and writes the previous in-memory incremental changes to the end of the temporary file, where Redis renames the old aof file, renames the temporary file, and begins writing to the new aof.

In case (the machine is broken or the disk is broken), it is best to back up the *rdb *.aof files generated with filesnapshotting or append-only to the remote machine on a regular basis . You can then use crontab timing (for example, every half hour) to SCP once.
If you do not use Redis's master-slave function, half-hour backup should be possible, and if the amount of application data is small, can be deployed, the master from a bit wasteful. It depends on the application.

The

Then specifically explains the two types of persistence:
rdb and aof respective advantages and disadvantages
1) rdb persistence benefits The
RDB is a very compact file that holds the data set of a redis at a point in time. This file is ideal for backups, for example, you can back up an RDB file every hour within the last 24 hours, and also back up an RDB file every day of the month. In this case, you can restore the dataset to a different version at any time, even if you encounter problems. The RDB is ideal for disaster recovery (disaster recovery): It has only one file, and the content is very compact and can be transferred (after encryption) to another datacenter, or Amazon S3. An RDB maximizes the performance of Redis: The only thing the parent process has to do when saving an Rdb file is to fork out a child process, and the child process will handle all subsequent save work, and the parent process does not have to perform any disk I/O operations. An RDB recovers a large data set faster than AOF.
    rdb persistence disadvantage
If you need to avoid data loss in the event of a server failure, the RDB is not appropriate. Although Redis allows you to set different savepoint (save point) to control how often an RDB file is saved, it is not an easy operation because the Rdb file needs to preserve the state of the entire dataset. Therefore, you may be able to save the Rdb file at least 5 minutes. In this case, the data may be lost for several minutes in the event of a failure outage. Each time you save an RDB, Redis will fork () out a subprocess and perform the actual persistence work by the child process. When the dataset is large, fork () can be time consuming, causing the server to stop processing the client in such milliseconds, and if the data set is huge and CPU time is very tight, the stop time may even be a full second. Although the AOF rewrite also requires fork (), there is no loss of data durability regardless of the length of the AOF rewrite execution interval.

2)aof Persistence Benefits
Using aof persistence makes Redis very durable (much more durable): You can set different fsync policies, such as no fsync, one fsync per second, or Fsync each time you execute a write command. The default policy for AOF is Fsync once per second, in which Redis can still maintain good performance and, even if there is a failure, it will lose at most one second of data (Fsync will execute in a background thread, so the main thread can continue to work on the command request). The AOF file is an append-only log file (append only), so the write to the AOF file does not require seek, even if the log contains incomplete commands for some reason (such as a write-in disk full, write-down, etc.), The Redis-check-aof tool can also easily fix this problem.
Redis can automatically override aof in the background when the aof file size becomes too large: The rewritten new aof file contains the minimum set of commands required to restore the current dataset. The entire rewrite operation is absolutely secure, as Redis will continue to append commands to the existing AOF file during the creation of the new AOF file, and the existing AOF files will not be lost even if there is an outage during the rewrite. Once the new AOF file is created, Redis switches from the old AOF file to the new AOF file and begins appending to the new AOF file. The AOF file preserves all write operations performed on the database in an orderly manner, and these writes are saved in the format of the Redis protocol, so the contents of the AOF file are easily readable and parsing (parse) is easy. The export AOF file is also very simple: for example, if you accidentally executed the Flushall command, but as long as the AOF file is not rewritten, just stop the server, remove the Flushall command at the end of the AOF file, and restart Redis to restore the dataset to Flushall the state before execution.
aof Persistence Disadvantages
For the same dataset, the volume of the aof file is usually larger than the size of the Rdb file. Depending on the Fsync policy you are using, the AOF may be slower than the RDB. In general, the performance of Fsync per second is still very high, while closing fsync can make aof as fast as an RDB, even under high load. However, the RDB can provide a more guaranteed maximum delay time (latency) when handling large write loads. AOF has been a bug in the past: Because of the reason of individual commands, the AOF file cannot be restored as it was when the data set was reloaded. (for example, a blocking command Brpoplpush has caused such a bug.) The test suite adds tests to this situation: they automatically generate random, complex datasets, and re-load the data to make sure everything is fine. Although this bug is not common in AOF files, it is almost impossible for an RDB to appear in comparison.

Which of the RDB persistence and aof persistence should be used?
In general, if you want to achieve data security that is comparable to PostgreSQL, you should use two persistence features at the same time.
If you are concerned about data, but can still tolerate data loss within a few minutes, you can use only the RDB persistence.
It is not recommended to use only AOF persistence: Because the scheduled generation of an Rdb snapshot (snapshot) is very convenient for database backups, and the RDB recovers the data set faster than the AOF recovery, the use of an RDB also avoids the previously mentioned AOF program bug.

RDB Snapshot
By default, Redis saves a database snapshot in a binary file named Dump.rdb. Redis can be set up to automatically save a dataset once the condition that the dataset has at least m changes in N seconds is met. You can also manually let Redis do the dataset save operation by calling Save or BGSAVE. For example, the following settings will allow Redis to automatically save a dataset when it satisfies the condition "at least 1000 keys are changed in 60 seconds":
Save 60 1000
This persistence is called snapshot (snapshot).

How an RDB Snapshot works:
When Redis needs to save the Dump.rdb file, the server performs the following actions:
Redis calls fork (), with both parent and child processes.
The child process writes the dataset to a temporary RDB file.
When a child process finishes writing to the new Rdb file, Redis replaces the original Rdb file with the new Rdb file and deletes the old Rdb file.
This way of working enables Redis to benefit from the write-time replication (copy-on-write) mechanism.
File only for append operation (append-only file,aof)
The snapshot feature is not very durable (durable): If Redis causes downtime for some reason, the server loses the data that was recently written and is still not saved to the snapshot. While the durability of data is not the most important consideration for some programs, the snapshot feature is less applicable for programs that pursue full durability.
Starting with version 1.1, Redis adds a completely durable way to persist: AOF persistence.
You can open the AOF feature by modifying the configuration file:
AppendOnly Yes
From now on, whenever Redis executes a command that changes the dataset (such as set), the command is appended to the end of the AOF file.
That way, when Redis restarts, the program can rebuild the dataset by re-executing the commands in the AOF file.

Below is the default snapshot setting for Redis:
Save 1       #当有一条Keys数据被改变时, 900 seconds refresh to disk once
Save     #当有10条Keys数据被改变时, 300 seconds to disk once
Save 10000    # When 10,000 keys data is changed, 60 seconds is flushed to disk once
redis does not break down because its write operation is in a new process.
When a new Rdb file is generated, the Redis-generated subprocess writes the data to a temporary file, and then renames the temporary file to an Rdb file by means of an atomic rename system call.
Redis's RDB files are always available for failure at any time.
Also, the redis's Rdb file is also a part of the Redis master-Slave synchronization internal implementation.
The first time slave synchronizes to master is that
Slave makes a synchronization request to master, and master dumps the Rdb file, and then transfers the Rdb file to slave in full volume. The master then forwards the cached commands to the slave and completes the initial synchronization. The
second and subsequent synchronization implementations are:
Master sends a snapshot of the variable directly to each slave in real time.
However, slave and master disconnection will repeat the two-step process for whatever reason. The master-slave replication of the
Redis is based on the persistence of memory snapshots, and there must be memory snapshots as long as there are slave. The
can obviously see that the RDB has its shortcomings, that is, once the database has a problem, then the data stored in our Rdb file is not entirely new. The
data from the last Rdb file generation to Redis outage was lost.

AOF rewrite:
Because AOF works by constantly appending commands to the end of a file, the volume of the AOF file becomes larger as the write command grows. For example, if you call a counter 100 times INCR, then just to save the current value of the counter, AOF file will need to use 100 records (entry). In practice, however, using only one SET command is sufficient to hold the current value of the counter, and the remaining 99 records are actually superfluous. To handle this situation, Redis supports an interesting feature: You can rebuild the AoF file without interrupting the service client (rebuild). To execute the bgrewriteaof command, Redis will generate a new aof file that contains the fewest commands required to rebuild the current dataset.

Interaction between the RDB and the AOF:
In Redis with a version number greater than or equal to 2.4, the BGSAVE does not perform bgrewriteaof during execution. Conversely, in the course of bgrewriteaof execution, BGSAVE cannot be executed.
This prevents two Redis background processes from doing large amounts of I/O to the disk at the same time.
If BGSAVE is executing and the user invokes the BGREWRITEAOF command, the server will reply to the user an OK state and inform the user that Bgrewriteaof has been scheduled to execute: Once the BGSAVE is executed, bgrewriteaof will be formally started. When Redis is started, if both RDB persistence and AOF persistence are turned on, the program takes precedence over the AOF file to recover the dataset, because the data that is stored in the AOF file is usually the most complete.

To back up Redis data:
Redis is very friendly for data backup because you can copy an RDB file when the server is running: Once the Rdb file is created, no modifications are made. When the server is about to create a new Rdb file, it saves the contents of the file in a temporary file, and when the temporary file is written, the program uses atomic to replace the original Rdb file with a temporary file. This means that, whenever an RDB file is copied, it is absolutely safe.

----------------------------------------------------------------------------------------------------------- --------------------------------------------------
Persistent policy tuning in the company's online Redis master-slave Environment:
Describe:
Prior to the previous project using Redis, the Redis master-slave environment was deployed, and the master Redis was persisted with aof and save snapshots. AOF files continue to grow and disk performance is gradually impacted.
So consider making some adjustments to redis persistence, with the following adjustments:
1) The main library does not do aof, do not do snapshot save, only one time every 12 o'clock in the evening scheduled task crontab do a snapshot and transfer to offsite. That is, Redis on the main library does not produce appendonly.aof persisted files, the snapshot content in the. rdb file (such as Dump.rdb, which is the snapshot file, which contains the data of the save snapshot, because it is a compression configuration, so the file size is smaller than the aof file. Specify a name in the configuration file, such as Dbfilename Dump.rdb), and then transfer the snapshot file Dump.rdb to another server to prevent the loss of the primary server downtime!
[Because in the configuration file, configured Rdbcompression Yes, that is, the snapshot file to compress, so the backup of the snapshot file Dump.rdb will appear to be smaller than the persistent file, it is normal! ]
In addition: The main library inserts a point-in-time (Crontab implementation) every 5 minutes, which makes it easy to record points of time from the library aof for fixed-point restores.
2) from the vault to open aof and 1 seconds to land, also do not do snapshot save. And at every 12 o'clock in the evening do a bgrewriteaof compression appendonly.aof persistent file, before compressing the backup.
----------------------------------------------------------------------------------------------------------- ---------------------------------
In this way, Redis persistence is adjusted, since the online master Redis takes the aof and save snapshot persistence, then both are turned off and persisted from the redis adoption of AOF. The following behavior occurs:
is when master Redis closes aof and save snapshots, The appendonly.aof persistence file on the master Redis is still in the brush for some time, it is normal, due to the previous turn on, brush over a period of time, the master Redis appendonly.aof persistence file is not brushed, only from the Redis appendonly.aof persistence The file's been brushed.
----------------------------------------------------------------------------------------------------------- ---------------------------------

Main purpose of Master-slave Redis deployment: Data persistence, disaster recovery, redundancy. The main library does not fall to the ground, reducing consumption.
1) The main library does not do aof, do not take snapshots, allow access from the library.
2) Open aof from library, do not save
3) Backup policy:
The main library makes a snapshot of each instance (Bgsave) every 12 o'clock in the evening.
Package Backup (TAR) of aof files serially from the library every 12 o'clock in the evening, and then do a aof file compression (BGREWRITEAOF) Once the backup is packaged. The data starting point of the day is the data after rewriteaof the night before.
The main library makes a snapshot (Bgsave) for each instance serially every 12 o'clock in the evening.
Main Library backup script (redis_bgsave.sh)

Main Library server script:
That is, after the main library snapshot, the snapshot files are transferred offsite from the library machine 192.168.1.121/135.

[email protected] redis]# cat redis_bgsave.sh#!/bin/bashcurhour= ' Date +%y%m%d_%h '/usr/local/bin/redis-cli-h 127.0.0.1-p 6379 bgsavesleep 10rsync-av/data/redis/dump.rdb [email protected]:/data/backup/192.168.1.132-save/$ Curhour/rsync-av/data/redis/dump.rdb [email protected]:/data/backup/192.168.1.132-save/$CURHOUR/sleep 10date > >/data/logs/bgsave.log

From the library server script:

[[email protected] redis]# cat redis_backup.sh#!/bin/bashcurdate= ' date +%y%m%d ' curhour= ' date +%y%m%d_%h ' curtime= ' Date +%y%m%d_%h%m%s ' logfile=/data/logs/redisbak/redis_allbak_${curdate}.logredisname=appendonly.7000ddir=/data/ backup/redis/$CURHOURmkdir-P ${ddir}rdir=/data/rediscd ${rdir}tar-zcf $DDIR/${redisname}_${curtime}.tar.gz APPENDONLY.7000.AOFIF [$?! = 0]; Then  echo "Tar error $REDISNAME. aof" >> $LOGFILEfisleep 5/usr/local/bin/redis-cli-h 127.0.0.1-p 6379 Bgrewrit Eaofsleep 5###  Delete old backup data dir  ####/bin/rm-rf ' date-d -30day + "%y%m%d" ' find/data/backup/redis/-mti Me +30 | Xargs Rm-rfecho "Backup $REDISNAME OK at $CURTIME!" >> $LOGFILE

[Email protected] redis]# CRONTAB-E
* * * */bin/bash/data/redis/redis_backup.sh >/dev/null 2>&1

[Email protected] redis]# cd/data/backup/redis/20161207_13
[[email protected] 20161207_13]# ls
Appendonly.7000_20161207_133131.tar.gz

-------------Look at one more example-------------------------------------------------------------------------------------------------------- -----------------------
Company online a project data storage using MySQL, a total of 10 libraries, distributed in 4 machines, each library data volume is about 10G, each machine uses RAID5 accelerated disk access;
When the number of online people at the Peak (10w), the DB disk IO pressure is huge, resulting in huge access, the number of online is very difficult to go.

As described above, the use of Redis can effectively solve this bottleneck, because Redis data read and write are directly within the operation.

Solution:
After the partial data compression is imported into Redis, the total data volume is approximately 30G (converted to the amount of data in Redis data type), one from the model and two groups.
A machine memory 32G, open 10 instances, a total of 20 instances, multi-instance to facilitate the persistence of a.

the same applies to the Redis persistence policy jump scenario above (that is , The Main Library does not do aof, do not do snapshot save, only at every 12 o'clock in the evening scheduled task crontab to take a snapshot and transfer to the offsite, the main library every 5 minutes to insert a point in time (Crontab implementation), convenient from the library AOF record time points for fixed-point restore. AoF persisted from the vault and landed in 1 seconds, also do not snapshot save. Do it once every 12 o'clock in the evening bgrewriteaof compression appendonly.aof persistent file, before compressing it for backup)

Backup backup strategy: The main library makes a snapshot of each instance (Bgsave) every 12 o'clock in the evening, and packages Backup (TAR) of aof files sequentially from the library every 12 o'clock in the evening, and AoF file compression (BGREWRITEAOF) Once the backup is packaged. The data starting point of the day is the data after rewriteaof the night before.
The main library makes a snapshot (Bgsave) for each instance serially every 12 o'clock in the evening. Main Library backup script (redis_bgsave.sh)

#!/bin/bash#date= ' Date +%y%m%d_%h%m%s ' redispassword=my#redisfor PORT in ' seq 6001 6020 ' do/usr/local/redis/bin/ Redis-cli-h 127.0.0.1-p $PORT-a $REDISPASSWORD bgsavesleep 10donedate >>/usr/local/redis/var/bgsave.log

Copy each instance's aof to a different directory and package it from the library every 12 o'clock in the evening, and compress the package to have an offsite backup before compressing aof (bgrewriteaof).
Backup aof from library and Bgrewriteaof script (redis_backup.sh: For a single instance)

#!/bin/sh## fd:file dir## rd:runing dir## The first parameter is a Redis instance name if [$#-ne 1]; Thenecho "usage:$0 redis_name" exitficurdate= ' date +%y%m%d ' curhour= ' date +%y%m%d_%h ' curtime= ' date +%y%m%d_%h%m%s ' Redispassword=my#redisredisname=$1port= ' echo $REDISNAME | Cut-c6-9 ' Logfile=/data/logs/redisbak/redis_allbak_${curdate}.logif ["${redisname}" = ""]; Thenecho "Redis name error!" Exit 1elseif [!-d "/data/redis-data/${redisname}"]; Thenecho "Redis name error!" Exit 1fifiddir=/data/backup/redis/$CURHOURmkdir-P ${ddir}rdir=/data/redis-data/$REDISNAMEcd ${rdir}tar-zcf $DDIR/$ {redisname}_${curtime}.tar.gz $REDISNAME. aofif [$?! = 0];  Thenecho "Tar error $REDISNAME. aof" >> $LOGFILE #exit 1fisleep 5/usr/local/redis/bin/redis-cli-h 127.0.0.1-p $PORT -A $REDISPASSWORD bgrewriteaofsleep 5### delete old backup data dir ####/bin/rm-rf ' date-d -7day + "%y%m%d" ' Find/data /backup/redis/-mtime +7 | Xargs Rm-rfecho "Backup $REDISNAME OK at $CURTIME!" >> $LOGFILE

Back up all instances from the library (/data/sh/redis_allbak.sh)

#!/bin/shcurdate= ' Date +%y%m%d ' logfile=/data/logs/redisbak/redis_allbak_${curdate}.logfor PORT in ' seq 6001 6020 ' do/ data/sh/redis_backup.sh Slave${port} && echo "Slave${port} OK ' date +%y%m%d_%h%m%s '" >> $LOGFILE 2> &1 | | echo "Slave${port} Backup Error" >> $LOGFILE 2>&1done

Operational considerations
1) If the main library is hung, the main library program cannot be opened directly. If you open the main library directly, it will flush out the AoF file from the library, which will cause you to restore only 12 of the previous night's backup.
2) The program can not restart the network when running (the program is read and write through the port of the network interface). A network outage will result in loss of data during the outage.
3) Determine that the configuration file is all right to start (especially if the data file name is not the same), otherwise it will flush out the original file, may cause unrecoverable loss.

Disaster recovery
1) Failure of the main library , quickly revert to the most recent status Description : The main library is hung (Redis program hangs/Machine down), from the Library normal, restore to the main library hangs off point of time: To do a snapshot from the library manually, copy the snapshot to the main library corresponding directory, start, OK.
In a snapshot from the library, transfer the snapshot files to a different directory, copy the snapshot file directory to the main library corresponding directory, launch the main library, ok!
(/data/sh/redis_bgsave_cp.sh)

#!/bin/bashredispassword=my#redisfor PORT in ' seq 6001 6020 ' do/usr/local/redis/bin/redis-cli-h 127.0.0.1-p $PORT-a $RE Dispassword bgsavesleep 5donesleep 15for PORT in ' seq 6001 6020 ' Dosdir=/data/redis-data/slave${port}/ddir=/data/redis_ Recovery/redis-data/mkdir-p $DDIR/redis${port}/cd $SDIRcp-rf slave${port}.rdb $DDIR/redis${port}/redis${port}.rdb# Sleep 1done

Rename the original data directory in the main library.
Copy snapshot files from the library to the main library.
Start the main library.

2) restore to the same day 12 point status note the backup data (the current state aof+ exit snapshot normally)!
Stop Redis.
Decompression AoF (/data/sh/redis_untar.sh)

#!/bin/bashday=20111102sdir=/data/backup/redis/20111102_00/cd $SDIRfor PORT in ' seq 6001 6020 ' dotar-zxf slave${PORT}_ $DAY _*.tar.gzsleep 2done cut aof (/data/sh/redis_sed.sh) #!/bin/bashddir=/data/redis_recovery/tag= "TAG111101_1200″ For PORT in ' seq 6001 6020 ' dosdir=/data/backup/redis/20111102_00/saof=${sdir}/slave${port}.aofline= ' sed-n "/$TAG/=" $ Saof ' num=$[$line + 3]mkdir-p ${ddir}/slave${port}/sed "${num},\ $d" $SAOF > ${ddir}/slave${port}/slave${port}. Aofdone

Rename the original data directory.
Rename the cut-out aof directory to the data directory of the configuration file. (Note the master-slave synchronization configuration item).
Start from the library.
Take a snapshot, copy to the main library, start the main library (same as 1th).

3) Restore to two days or a few days before the 12 point state from the library nightly backup to back up aof data before bgrewriteaof , can be based on the same day 12 o'clock backup, there is no bfrewriteaof before the aof file to recover, method with the above 2nd) step.

Redis Persistence strategy grooming and policy adjustment record in master-slave environment