The aof of Redis persistence (III.)

AOF (appendoffile) Introduction:

Record each write in the form of a log, record all the write commands performed by Redis (read operation not recorded), only append files but not overwrite files, Redis startup early read the file to reconstruct the data, in other words, When Redis restarts, the write instruction is executed from front to back based on the contents of the log file to complete the recovery of the data.

That is to say, AOF will all the write operations in the form of a daily log to the file, and this time interval is 1 seconds, then all the records are absolutely correct, and not like the Rdb lost the last saved data, then the problem, if the number of operations, the more Then there are also more records, log files are larger, such as

Set K1 1
incr k1
incr K1
incr K1
incr K1
incr K1
incr K1
incr K1
incr K1
incr k1
  INCR K1
incr K1
incr K1
...

Here K1 every time it grows, but the answer is yes if we do

Set K1 100

100 indicates the number of times we grow, which is not more efficient than INCR's command, but it can also prevent mistakes, which is AOF's shortcomings

aof Configuration Introduction:

The default is not to turn on aof, because Redis thinks that the RDB is sufficient to meet the needs of persistence, so here we need to modify the configuration, start aof

OK, after the start, then there are two persistent strategies, then this time there will be a problem.

This is not a conflict, because the RDB do the rdb thing, aof dry aof, so you can rest assured that the use, there will be no conflict

First delete the previously generated DUMP.RDB

After executing the above command we can see that there will be appendonlyfile.aof files in the Redis installation directory, then we can open the

We can see that all of our write operations are recorded here, so the next step is to restart the Redis service to see if those actions will recover

After the connection we found that the previous operation did not recover, this is what is going on. Do you remember that I executed the Flushall command, yes that is the order of the Ghost, in fact, has been restored, but after the recovery and then executed the Flushall operation, and then the data to be emptied. OK then we will manually delete the Flushall command, so that the data normal recovery

At this point, we'll start redis again and we'll see that all of it has been restored ( Note: If you haven't recovered a moment later, it's possible that Redis has not read aof)

The part of the red box is to simulate the error in logging the write operation, then we start the Redis service again and connect

The Redis service could not be connected at this time because it was the previous. AoF an exception occurred during the read process, causing the connection to fail. Then this time the description of the. aof file is read beforehand. So how to fix it. is not that we use VIM or VI manually to remove the unknown content just now. That's definitely not it.

You can see there is a redis-ckeck-aof in the Redis installation directory, this is used to repair the AoF file, execute the command

This time open the AoF file again

At this point, the unknown string has been found.

Then this time start the Redis service again and connect

At this point, we find that we can use Redis as normal.