1, AOF persistence configuration
AOF persistence, is off by default, the default is to open the RDB persistence
appendonly yes, you can open AOF persistence mechanism, in a production environment inside, in general AOF it is to be opened, unless you say that throwing a few minutes of data does not matter
After opening AOF persistence mechanism, redis each time it receives a write command, will be written to the log file, of course, is to write os cache, and then again at regular intervals about the fsync
And even if AOF and RDB are opened, redis restart time, is also a priority for data recovery by AOF, because aof more complete data
You can configure the AOF fsync strategy, there are three strategies can be selected, one is a data write is executed every time a fsync; one is performed once every second fsync; one is not performed actively fsync
always: Every piece of data is written immediately after the corresponding write this log data to disk fsync up, very, very poor performance, throughput is low; ensure that the data in a redis say do not lose, then this is it
mysql -> memory policy, a large number of disks, QPS to the number, twelve k. QPS, the number of requests per second
redis -> memory, disk persistence, how much QPS, single, generally speaking, no problem of thousands of QPS
everysec: per os cache data in the fsync to disk, the most commonly used, the production environment in general are so configured, high performance, QPS can still thousands of
no: redis only responsible for writing data to os cache wash their hands, and then they will from time to time behind the os have its own policy data into the disk brush, the uncontrollable
2, AOF persistent data recovery experiment
(1) first open only RDB, write some data, and then kill -9 redis kill the process, and then restart redis, found that the data did not, because not generate a snapshot RDB
(2) Open AOF switch enabled AOF persistence
( 3) writes some data to observe the contents of the log file AOF
In appendonly.aof file, you can see the log just written, they are written to os cache first, and then after 1s fsync to disk, only fsync to disk is safe, just in os cache in,
The machine restarts, you have nothing.
(4) kill -9 to kill the process, restart redis, data is restored back. It is to restore the file back from aof
redis process startup, will load directly from appendonly.aof log in to restore the data in memory back.
3、AOF rewrite
Data redis in fact limited, a lot of data may be automatically expire, the user may be removed and may be removed redis caching algorithm clean out
The data redis will continue to eliminate old, on a portion of the commonly used data is automatically retained in memory redis
Before it may have been cleaned up a lot of data, corresponding to the write log is still stuck in the AOF, AOF on a log file, we will continue to expand, to very big
So AOF rewrite operation is automatically done in the background at regular intervals, such as log has been stored for a written log of the data 100w;
redis memory only 100,000; memory-based data in the current 100,000 to build a new log, the AOF in;
Cover the old log before; ensure AOF log files are not too large, consistent with the amount of memory data redis
Before redis 2.4, also you need to manually develop some scripts, crontab, by BGREWRITEAOF command to execute AOF rewrite, but after redis 2.4, will be automatically rewrite operation
In redis.conf, you can configure rewrite policy
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
For example, after the last AOF rewrite is 128mb
Then we will then continue to write 128mb AOF log, if found to increase the proportion of more than 100% before, 256mb, it could trigger a rewrite go
But this time even to talk to min-size, 64mb to compare, 256mb> 64mb, only to trigger rewrite
(1) redis fork a child process
(2) sub-process based on the data currently in memory, build log, to begin a new temporary file written to the log AOF
after (3) redis main process, the client receives a new write operation is written to the log in memory while also continue to write new log file AOF old
after (4) the child process to finish a new log file, redis main memory in the process of re-added to the new log file in the new AOF
(5) with a new log files replace the old log files
4, repair damaged files AOF
If redis file in append data to AOF, machine downtime, and may result in damage AOF file
With redis-check-aof --fix command to repair the damaged file AOF
5, AOF and RDB simultaneously
(1) If the RDB snapshotting operation performed, then redis not perform AOF rewrite; if then redis performed AOF rewrite, it will not be executed snapshotting RDB
(2) If the execution snapshotting RDB, then the user BGREWRITEAOF execute command, etc. after the RDB snapshot generation, only to rewrite the implementation of AOF
(3) while RDB snapshot AOF files and log files, then redis restart when the AOF will give priority to the use of data recovery, because the more complete logs
(1) While there appendonly dump and aof the rdb's, rdb also has some data, aof also has some data, this time in fact find, rdb data is not restored to the memory
(2) We simulate make aof damaged and then fix, there is a fix data will be deleted
(3) again with the fix was aof file to restart redis, found that only one of the data
Data recovery is entirely dependent on the persistence of the underlying disk, no data on the main rdb and aof, that is gone