redo log (physical log)
The InnoDB storage engine manages storage space in units of pages. The operations of adding, deleting, modifying, and retrieving are to load the data of the page into the memory, and then perform the operation, and then flash the data back to the hard disk.
Then the problem is coming. If I want to transfer 100 yuan to Zhang San, the transaction has been submitted. At this time, InnoDB loads the data into the memory. At this time, I haven't had time to flash it into the hard disk. Sudden power failure and the database collapsed. After restarting, I found that my money was not successfully transferred. Isn't that embarrassing?
The solution is obvious. After the hard disk is loaded into the memory, we perform a series of operations. The operation is as fierce as before. Before being refreshed to the hard disk, record it first. The amount in my record is reduced by 100 in XXX position. Add 100 to the amount in the three records, and then add, delete, modify, and check, and then flash into the hard disk. If the hard disk is not flashed, after restarting, the previous record is loaded first, then the data comes back.
This record is called the redo log, or redo log. His purpose is to make the data modification of the committed transaction permanent, even if he restarts, the data can be recovered.
log buffer
In order to solve the problem of too slow disk speed, the redo log cannot be directly written to the disk, we first put a large continuous memory space for him to put data. This large piece of memory is called the log buffer, or log buffer. When the time is right, flash the hard drive again. As for when it is appropriate, this next chapter says.
We can show VARIABLES like 'innodb_log_buffer_size'check the current log cache size through commands. The figure below shows the online size.
Redo log timing
Since the redo log is always growing, and the memory space is limited, the data cannot be kept in the cache all the time, we need to refresh it to the hard disk.
When will it be refreshed to the hard disk?
- There is not enough space in the log buffer. There is a specified buffer memory size, MySQL believes that the log volume has accounted for about half of the total capacity, you need to refresh these logs to disk.
- When the transaction is committed. The purpose of our redo log is to save his records that have not been refreshed to disk to prevent loss. If the data is submitted, we can not submit the data to disk, but in order to ensure durability, we must modify the redo of these pages The log is flushed to disk.
- Different background thread refresh There is a thread in the background, which will refresh the redo log in the log buffer to the hard disk about every second.
- checkpoint in the next section
redo log file group
We can show variables like 'datadir'find the relevant directory through the command, there are two files underneath, namely ib_logfile0 and ib_logfile1, as shown in the figure below.
We refresh the redo log in the buffer log buffer into these two files. The way they write is written cyclically, first write ib_logfile0, then write ib_logfile1, wait until ib_logfile1 is full, then write ib_logfile0. Then there will be a problem. If ib_logfile1 is full, then write ib_logfile0. Isn't the content of ib_logfile0 overwritten and lost? This is the job of checkpoint.
checkpoint
The redo log is for restoring dirty pages after a system crash. If the dirty pages can be flushed to disk, then he can retire, and it will be okay to be overwritten.
Conflict tutorial
From the beginning of system operation, the page is continuously modified, and redo logs are continuously generated. The redo log is constantly increasing, and MySQL has taken a name for it, Log Sequence Number, or lsn for short. His initial value is 8704, used to record how many redo logs are currently generated.
The redo log is written to the log buffer first, and then it is flushed to the redo log file on disk. MySQL named it flush_to_disk_lsn. Used to indicate how much dirty page data in the cache area is flushed to disk. His initial value is the same as lsn, and there will be a gap later.
There are two steps to do a checkpoint
- Calculate the maximum lsn corresponding to the redo log that can be overwritten by the current system. The redo log can be overwritten, which means that the dirty page corresponding to it is flushed to disk. As long as we calculate the oldest_modification that was modified in the current system the earliest, as long as the lsn in the system is less than the oldest_modification value of the node, the redo log of the disk can be Covered.
- Statistics of some data in the process of lsn.
Author: little sister Learning Java
link: https: //juejin.im/post/5dfc846051882512327a63b6
Source: Nuggets
copyright reserved by the authors. For commercial reproduction, please contact the author for authorization, and for non-commercial reproduction, please indicate the source.