Redis persistence options? What are the advantages and disadvantages?

Redis persistence mode

Persistent meant to do disaster recovery, data recovery. Since Redis of all data in memory inside, if Redis hung up, no persistent, then restart when the data will be lost.

Suddenly, a large number of requests over, not all the cache hit, causing an avalanche cache, mysql can not carry a lot of requests, causing the whole system to crash. If Redis persistence to do, even if Redis fault, and also be able to restart immediately, to provide services.

Redis persistence divided into two types:

RDB persistence : within the specified time interval the memory snapshot of a dataset is written to disk, the actual operation is fork a child process, the first set of data written to a temporary file, after writing success, and then replace the file before, binary compressed storage.
AOF 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 .

By RDB and AOF, can Redis data memory persisted to disk, can also be assigned to other places, such as Ali cloud and so on. If Redis hung up, Ali goes from disk or copy data to places like Redis, the restart Redis, Redis will automatically reconstruct the data according to the file.

If you use RDB and AOF two kinds of persistence mechanism, so when redis restart, AOF will be used to reconstruct the data because the data AOF is more complete.

RDB persistence configuration:

Redis snapshots will dump data set to dump.rdb file. In addition, we can also be modified by the frequency Redis server configuration file dump snapshot, after opening 6379.conf file, we search save, you can see the following configuration information:

 　900. 1 Save               # After 900 seconds (15 minutes), if at least one key is changed, the dump memory snapshot. 
   Save 300 10              # after 300 seconds (5 minutes), at least if there is a change key 10, the dump memory snapshot. 
   Save 60 # 10000 after 60 seconds (1 minute), if at least 10,000 key changes, the dump memory snapshot.

AOF persistence configuration:

In the present embodiment three kinds of synchronous Redis profile, they are:

  appendfsync always # every time a data modification occurs when a file is written to AOF. 
  appendfsync everysec # sync once per second, the strategy is the default strategy of AOF. 
  appendfsync no # Never synchronization. Efficient but the data are not persisted.

RDB and the advantages and disadvantages of AOF

RDB advantages and disadvantages:

Once this manner, then your entire Redis database will contain only one file, which for file backup is perfect. For example, you might intend to archive every hour last 24 hours of data, but also archived once in the last 30 days of data every day. With this backup strategy, once the system has failed catastrophically, we can very easily be restored.
AOF relative persistence mechanism, the process to restart and restore redis more quickly and directly based on the RDB data files.
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 be.
For disaster recovery purposes, RDB is a very good choice. Because we can very easily be a separate file compression and then transferred to other storage media.
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 longer generation time, this time you have to accept the redis Once the process down, then lost the last five minutes of data.
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.

AOF advantages and disadvantages:

AOF can better protect data is not lost, AOF will generally every second, once fsync operation executed by a background thread, losing up to 1 second of data.
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. If we write this operation is only half the data appeared system crash, do not worry, until the next time you start Redis, we can to help us solve the problem of data consistency by redis-check-aof tool.
AOF log file is too large even when the background rewriting operation occurs, it will not affect the read-write client. Because when the rewrite log, which will compress command, create a minimum number of log data you need to recover it. When you create a new log file, 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. Therefore, when switching is performed rewrite data security can be guaranteed better.
AOF clear to a format that is easy to understand the log file to record all the changes, very suitable 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 aof the file back, you can recovery mechanism automatically restore all the data.
For the same number of data sets, AOF is generally larger than RDB document file. RDB speed when recovering large data sets faster than the speed of recovery of AOF.
After AOF turn, will support backed write QPS QPS lower than the RDB write, because AOF generally configured to fsync the log file once per second.
Class like this more complex AOF based command 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.

how to choose?

How RDB and AOF choose?

Do not just use RDB, because that would cause you to lose a lot of data;
Do not just use the AOF, because that there are two problems: First, you do cold standby by AOF, do not RDB cold standby to recover faster; second, RDB data snapshot is generated every time simple and crude, more robust, this bug can be avoided AOF complex backup and recovery mechanisms;
redis support open simultaneously open two kinds of persistent way, we can use the integrated AOF and RDB two kinds of persistence mechanism, with AOF to ensure that data is not lost, as the first choice for data recovery; RDB to do with varying degrees of cold standby, when AOF files are missing or damaged unavailable, you can also use RDB for fast data recovery.