What is binlog in MySQL?
Review the content of the previous article
In the previous article, I introduced the architecture of the InnoDB engine, and also mentioned three redo log log loss strategies
Next, we continue the content of the previous lecture to explore what binlog in MySQL is.
What is binlog?
In the last lecture, we learned about redo log, which is biased towards physical properties. It records what changes have been made to which record of which data page 是属于InnoDB所特有的. Remember, I hope everyone will keep this in mind.
The binlog is called an archive log, which also records the operations performed, but a little bit different is more logical, similar to "update the data in the users table with id=10, and the updated value is' Xiao Ming'",它是属于MySQL Server自己的日志文件
Therefore, when committing the transaction, not only will the redo log be written to the disk, but also the binlog log corresponding to this operation will be written to the disk file. It should be noted that the binlog log is written to the disk. It does not go through the InnoDB engine
Similar to the redo log flushing strategy mentioned earlier, the binlog log also has a flushing strategy. You can use the following method to see which way you are using MySQL by default
mysql> show variables like '%sync_binlog%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog | 1 |
+---------------+-------+
1 row in set (0.02 sec)
-
sync_binlog=0
At this time, when you write the binlog to the disk, it is not directly into the disk, but into the os cache memory cache.
-
sync_binlog=1
When you commit the transaction, the binlog will be forced to be written to the disk, even if the machine goes down after the transaction is committed, the binlog data on the disk will not be lost
How to complete the transaction commit after having binlog?
When the transaction is finally committed, the file name and path of the binlog file corresponding to the transaction will be written to the redo log, and a commit mark will be written. After the above operations are completed, the transaction is considered to be submitted.
At this point you may ask, why add this last step?
In fact, the purpose of this step is to ensure that the redo log and binlog data are consistent. If only step 5 is completed or only step 5 and 6 are completed, as long as the machine suddenly crashes before step 7 is executed, then this time The transaction will be judged as a transaction commit failure because there is no commit mark in the redo log
How is dirty data flushed into memory after the transaction is committed?
When an update occurs, once the transaction is submitted successfully, there will be corresponding data in the redo log log and will be marked by commit. No matter whether the system is down or not, there will be no data loss. It is easy to think of the disk The data in must also need to be updated sooner or later, but how is it updated?
There is an IO thread in MySQL that is specifically responsible for flushing dirty data to disk from time to time. It will pick a database when the pressure is not so high to perform these operations
Speaking of this, the basic architecture of InnoDB is almost the same. Looking back at the content mentioned before, you have wondered why the file on the disk is not directly modified during the update operation but through the Buffer Pool, undo log, redo log, binlog , Submit transactions, dirty data so many things to complete the data update?
To modify the files on the disk but to complete the data update through Buffer Pool, undo log, redo log, binlog, commit transaction, dirty data, etc.?
I believe most of the friends can tell why, because when we perform the update operation, we perform random reads and writes to the disk. If we directly manipulate the data on the disk, the speed is very slow, but, Cache the data in the Buffer Pool and modify it based on the memory will greatly improve the speed, and then write redo log, binlog log to ensure the security of the data, you may want to write redo log And binlog is not also writing data to disk? Isn't the efficiency very low? However, although this is an operation on the disk, it does read and write sequentially. Compared with random read and write, the efficiency of sequential read and write of the disk is very high. Therefore, the InnoDB engine, through the above seemingly complicated steps, in exchange for the high concurrency performance of the MySQL database