Shulou(Shulou.com)05/31 Report--

Today, I will talk to you about the usefulness of aof log files, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following contents for you. I hope you can get something according to this article.

In the Redis configuration file, there is an option called appendonly, which can write yes or no. This option is responsible for whether to turn on the AOF log switch. AOF log, you can simply understand as the same thing as MySQL binlog, the function is to record each write operation, in the event of a power outage and other problems can be used to restore the state of the database. But he is not bin's, but text's. One line at a time, the writing is very standard. If you are a redis, you can also recover data through it. The following editor will explain the usefulness of aof (append only file) log files.

What is the use of aof (append only file) log files

Redis has three types of landing files:

Data file-its location and file name can be set in the configuration. The default file name is dump.rdb

Log files-can also be configured in the configuration. Of course, when you are running in daemon mode, do not set this value to stdout, this setting will be automatically changed to / dev/null

AOF file-the protagonist of our article, whose role is for data recovery. In addition to setting whether it is turned on or not, he can also set how to write logs after it is turned on. There are three kinds of this: 1 is guaranteed to complete fsync () for each write operation, 2 is to call fsync () once per second, and 3 is never called, leaving the operating system to synchronize itself. Of course, if the setting is different, the efficiency will be different and your risk of data loss will be different.

Running process

Since it is a log file, and it is used for recovery, then we can think of it by moving our toes. No matter whether your application is big or small, if the AOF file is added, the file will grow infinitely, which is a problem that all binlog will encounter. But usually encounter this kind of problem, there will be a rotate scheme. It means that the log reaches a certain size or writes the log to a new file at regular intervals, and the old log file can be used for backup or other.

Redis's AOF is also slightly different from rotate. He uses a simpler method, which is to take a snapshot of all the current data first. Then write the following log on the basis of this snapshot.

The advantage of snapshots is that you may have used 10w operations to change 100 pieces of data (for example, multiple operations on one piece of data). At this point, the 10w write records in your AOF become 100 records. It is equivalent to merging all the previous implementations. It used to be big and AOF is getting smaller.

The command to do this is: BGREWRITEAOF (background rewrite append only file)

What does this snapshot look like? Basically, it is no different from the general log writing, and it is also a written record.. For example, there are always 3 pieces of data of string type a = > 1 Magi b = > 2 Magi c = > 3 in Redis. The basic content of this snapshot is to write a = > 1, b = > 2, and c = > 3.

When you want to restore with AOF, as long as you execute the first few items first, you can restore the current state, and then perform the subsequent write operation, and then you can completely reproduce the data.

What is the use of aof (append only file) log files

Internal implementation

We have a rough idea of what happens when BGREWRITEAOF is executed, so let's talk about how Redis is implemented. Divide it into the following steps:

Fork! Redis generates child processes through fork.

The child process traverses the current data, generates a write log for all the current data, and writes these logs to a temporary file. (in fact, the child process wrote a temporary file, and then rename became another temporary file.)

The parent and child processes execute in parallel. When the child process traverses and writes temporary files, the parent process receives the request, processes the request, and writes the AOF as usual, but at this time he writes the new AOF in a buffer.

When the child process finishes traversing and writes the temporary file, it exits. At this point, the wait3 function of the parent process will receive the message that the child process exits, and it will append all the AOF he has collected in the buffer to the temporary file.

The last step is to rename the temporary file and rename it to appendonly.aof, when the original aof file is overwritten. The whole process is complete.

If your AOF file is slightly larger, you can execute BGREWRITEAOF on a terminal, and then immediately ls to check the redis data directory several times, you can see that the temporary file has become a temporary file, the temporary file is smaller than the original appendonly.aof, and then the temporary file disappears, while the original appendonly.aof becomes smaller, in fact, the temporary file rename becomes appendonly.aof... The original large file was overwritten. Looks like the temporary file disappeared.

After reading the above, do you have any further understanding of the use of aof log files? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.