1 Introduction, RDB and two kinds of persistence mechanism AOF
RDB persistence mechanism, the data in periodic execution redis persistence
AOF each mechanism as a log write command, writes to a log file append-only mode, when redis restart, may be re-build the entire data set by playing back the log write instruction AOF
If we want to redis only as a pure memory cache to use, you can disable all the persistence mechanism RDB and AOF
By RDB or AOF, you can be redis memory data to be persisted to disk above, then these data can be backed up to go somewhere else, such as Ali cloud, cloud services
If redis hung up the data on the disk and memory on the server are lost, you can copy the data back from the cloud before serving, put the specified directory, then start again redis, redis persistent data file automatically based on the data, to restore data in memory, continue to provide services
If you use RDB and two types of persistence mechanisms AOF, then when redis restart, AOF will be used to reconstruct the data because the data is more complete AOF
-------------------------------------------------------------------------------------
2, RDB persistence mechanism advantages
(1) RDB generates a plurality of data files, each data file is data representing a certain moment in the redis, this way of a plurality of data files, very suitable for cold standby, this may transmit the complete data file some remote storage up security, such as Amazon's S3 cloud service up in the country may be on the ODPS Ali cloud storage distributed to the scheduled backup policy to back up data regularly in redis
RDB can do cold standby, generate multiple files, each file represents a complete snapshot of the data one time
AOF can do cold standby, only one file, but you can, at regular intervals, to copy a this file out
RDB do cold standby, advantages Where is it? Redis to control the length of time the snapshot file to generate a fixed thing, more convenient; AOF, also need to write some scripts to do this thing, various timing
RDB data do cold standby, in the worst case, when providing data recovery, faster than AOF
(2) RDB read and write redis provide external services, the impact is very small, can make redis maintain high performance, because redis main process requires only fork a child process, so that the child process to perform disk IO operations to RDB persistence can
RDB, each write, write redis are direct memory, but at some point, will write data to disk in
AOF, each time to write the file, although you can quickly write os cache, but it still has some time overhead, speed is definitely a little slower than some of RDB
(3) with respect to the AOF persistence mechanism, the direct-based RDB data files to restart and restore redis process, faster
AOF, instructions stored in the log, do data recovery when, in fact, is to be played back and execute all instructions logs to recover all the data out of memory
RDB, is a data file, recovery time, directly loaded into memory to
Combination of these advantages, a RDB particularly suitable for cold backup, Cold Standby
-------------------------------------------------------------------------------------
3, RDB persistence mechanism shortcomings
(1) If you want to redis failure when, as little as possible loss of data, then the RDB no good AOF. In general, RDB data snapshot files, are every 5 minutes, or generated once more, this time you have to accept the redis Once the process down, then lost the last five minutes of data
This issue, but also rdb biggest drawback is not suitable for recovery programs first priority, if you rely on to do the first priority RDB recovery program, will lead to more data loss
(2) RDB in each fork child process to execute when RDB snapshot data files generated, if the data file is particularly large, may result in suspension of service provided to clients milliseconds, or even seconds
Do not let the general RDB interval is too long, otherwise the RDB is generated every time a file is too large, it may have an impact on the performance of redis itself
-------------------------------------------------------------------------------------
4, AOF lasting advantage of the mechanism
(1) AOF can better protect data is not lost, AOF will generally every second, through a background thread to perform a fsync operations, data loss of up to 1 second
Every one second, fsync operation is executed once, to ensure os cache data is written to disk
redis process hung up, lose up to one-second data
(2) AOF log files are written in append-only mode, so there is no disk seek overhead, write performance is very high, and the file is not easily damaged, even if the end of the file is damaged, and very easy to repair
(3) AOF log file is too large even when the background rewriting operation occurs, it will not affect the client to read and write. Because in the rewrite log, and will guide them to compress, to create a minimum number of log data you need to recover it. Then create a new log file when the old log file is written as usual. When the log file after the new merge ready, and then exchange the old and new log files.
(4) command AOF log files are recorded in a very readable way, this feature is ideal for emergency recovery of accidentally deleted disastrous. For example, someone accidentally with flushall command to clear all the data, as long as this time backstage rewrite has not happened, then you can immediately copy AOF files, last flushall command to delete, and then put the file back AOF, you can by recovery mechanism automatically restore all data
-------------------------------------------------------------------------------------
5, AOF persistence mechanism shortcomings
More (1) for the same data is, AOF log file often than RDB data snapshot file
After (2) AOF open, backed write QPS will write lower than the RDB support QPS, because AOF generally configured to fsync the log file once per second, of course, once per second fsync, performance is still very high
If you want to ensure that a data is not lost, it is also possible, AOF of fsync did not write a data set, fsync once it finished, QPS drop of redis
Times (3) formerly AOF bug happened, AOF is through the log records, data recovery, no recovery of data out exactly the same. So, similar to the AOF this more complex commands based on the log / merge / playback mode, based on the RDB than each persistent file a complete snapshot of the data the way some of the more fragile, prone to bug. But AOF is to avoid bug rewrite process caused so each rewrite is not performed merge is based on the old command log, but to re-build instructions based on the data in memory at the time, this will be much better robustness.
(4) The only drawback is relatively large, in fact, do data recovery time will be slower, and do cold standby, regular backup, is not convenient, you may want to do their own handwriting complex script, do not prepare cold too appropriate
-------------------------------------------------------------------------------------
6, RDB and AOF in the end how to choose
(1) Do not just use RDB, because that would cause you to lose a lot of data
(2) Do not just use the AOF, because that there are two questions. First, do you cold prepared by AOF, do not RDB cold standby to recover faster; second, RDB data snapshot is generated every time simple and crude more robust, bug can be avoided AOF this complex backup and recovery mechanisms
(3) and the integrated use of two kinds of persistence mechanisms AOF RDB, AOF used to ensure that data is not lost, as the first selection data recovery; do RDB with different degrees of cold standby, are lost or corrupted file unavailable AOF time, you can also use RDB for rapid data recovery