MySQL combat optimization expert 04 uses the execution process of update statements in the InnoDB storage engine to talk about what binlog is?

1、 The last lesson is about the solution of thinking problems ：redo Suggestions on the selection of log disk brushing strategy

First, I'll explain to you the thinking problem of the previous lecture , I give you a suggestion , In fact, for redo Three disk flushing strategies for logs , We usually suggest setting by 1

in other words , When you commit a transaction ,redo The log must be brushed into the disk file .

This can strictly ensure that after the transaction is committed , Data is never lost , Because there is redo The log in the disk file can recover all your repairs Change .

If you choose 0 Words , Maybe after you submit the transaction ,mysql Downtime , So at this time redo The log is not flushed , Cause... In memory redo Log lost , The updated data of the transaction you submitted is lost ;

If you choose 2 Words , If the machine goes down , Although when the transaction was committed before ,redo Log entry os cache 了 , But it hasn't entered the disk text yet Pieces of , At this time, machine downtime will still lead to os cache Inside redo Log lost .

So for a strict system like a database , General advice redo The log disk brushing policy is set to 1, Ensure that after the transaction is committed , Data must not be lost .

2、MySQL binlog What is it ？

Then let's take a look at MySQL binlog What is it ？

In fact, what we said before redo log, It is a redo log biased towards physical properties , Because he recorded something like this ,“ To which What records in the data page , What changes have been made ”.

and redo log It belongs to InnoDB Something unique to the storage engine .

and binlog It's called archive log , What he records is a log that tends to be logical , Be similar to “ Yes users In the table id=10 A row of data has been updated do , What is the updated value ”

binlog No InnoDB Storage engine specific log files , It belongs to mysql server Your own log file .

3、 When you commit a transaction , It also writes binlog

So in fact, we talked about , When we submit the transaction , Will be able to redo log The log is written to the disk file . Then, when the transaction is committed Hou , We will also update the corresponding binlog Log is written to disk file , As shown in the figure below .

             

You can see some changes in this picture , I'm the one who told you InnoDB The component that the storage engine interacts with adds the actuator component mentioned before , He will be responsible for following InnoDB Interact , Including loading data from disk to Buffer Pool Cache in , Include write undo journal , Including updates Buffer Pool The data in , And write redo log buffer,redo log Brush in the disk , Write binlog, wait .

actually , The actuator is a very core component , Responsible for cooperating with the storage engine to complete a SQL Statement all data update operations at the disk and memory levels do .

And we can see in the picture above , I put the execution of an update statement , Split into two phases , In the picture above 1、2、3、4 Several steps , In fact, the essence It's what you do when you execute this update statement .

Then... In the figure above 5 and 6 Two steps , It started when you submitted the transaction , It's time to commit the transaction .

4、binlog Analysis of the strategy of the log disk brushing

about binlog journal , In fact, there are also different strategies for disk brushing , There is one sync_binlog Parameters can be controlled binlog The strategy of disk brushing , His default value is 0, At this point, you binlog When writing to disk , It's not going directly to the disk file , But into os cache Memory cache .

So it's the same as the previous analysis , If the machine goes down at this time , So you are in os cache Inside binlog Logs are lost , Let's see the diagram below

             
If you put sync_binlog Parameter set to 1 Words , At this point, it will be forced to commit the transaction , hold binlog Write directly to the disk file , So after committing the transaction like this , Even if the machine goes down , On disk binlog It won't be lost , As shown in the figure below

            

5、 be based on binlog and redo log Complete transaction commit

When we put binlog After writing to disk file , Then the final transaction submission will be completed , At this time, the corresponding binlog File name and this time The updated binlog The location of the log in the file , All written to redo log Go to the log file , At the same time redo log Write a... In the log file commit mark remember .

After finishing this thing , The transaction submission is finally completed , Let's see the diagram below .

           

6、 The last step is redo Write... In the log commit What is the meaning of the mark ？

At this time, some students must ask , Last in redo Write... In the log commit What's the point of marking ？

To put it bluntly , He is actually used to keep redo log Journal and binlog Log consistent .

Let's give you an example , Suppose we commit a transaction , There are... In the figure above 5、6、7 Three steps , All three steps must be completed , In order to be Is the transaction committed . So after we've just completed the steps 5 When , That is to say redo log When I just swiped in the disk file ,mysql It's down. , How about now do ？

At this time, because there is no final business commit Mark in redo In the Journal , Therefore, this transaction can be judged as unsuccessful . I won't say redo In the log file There is a log of this update , however binlog There is no log of this update in the log file , There will be no data inconsistency .

If steps are completed 6 When , That is to say binlog Written to disk , here mysql It's down. , What do I do ？

Empathy , Because no redo log In the end commit Mark , Therefore, the transaction commit also fails at this time .

Must be in redo log Write the final transaction in commit The tag , Then the transaction is committed successfully , and redo log There is the day corresponding to this update Records ,binlog There is also the log corresponding to this update ,redo log and binlog Exactly the same .

7、 backstage IO The thread randomly brushes the dirty data after memory update back to disk

Now let's assume that the transaction has been committed , At this time, an update “update users set name='xxx' where id=10”, He has put... In memory buffer pool The cached data in is updated , At the same time, there are redo Journal and binlog journal , It's all recorded what we designated “id=10” This line of data Revised “name='xxx'”.

At this point, we will think about a problem , But at this time, the data in the data file on the disk “id=10” This line of data name The field is still equal to zhangsan This old value ！

therefore MySQL There is a backstage IO Threads , At some later time , Randomly put the memory buffer pool The modified dirty data in is brushed back to the magnetic Go to the data file on the disk , Let's look at the picture below ：

             

When in the picture above IO Thread buffer pool After the modified dirty data in is brushed back to the disk , The data on disk will be the same as in memory , All are name=xxx The modified value ！

In you IO Before the thread brushes dirty data back to disk , Even if the mysql It doesn't matter if it goes down or crashes , Because after the restart , Will be based on redo The premise of log recovery Do the modifications you have made to the memory , Namely id=10 Data. name Revised to xxx, Then wait for the right time ,IO The thread will naturally modify this After the data is brushed into the data file on the disk

8、 Based on the process of updating data , To sum up InnoDB The architecture principle of storage engine

Let's go through the process of updating data , You can clearly see ,InnoDB The storage engine mainly includes some buffer pool、redo logbuffer Wait for the cached data in memory , It also includes some undo Log files ,redo Log files and other things , meanwhile mysql server I have binlog Log files .

When you execute the update , Every one of them SQL sentence , Will be modified accordingly buffer pool Cache data in 、 Write undo journal 、 Write redo log buffer A few A step ;

But when you submit a transaction , I will redo log Brush in the disk ,binlog Brush in the disk , complete redo log The transaction commit Mark ; Last Backstage IO Threads will randomly put buffer pool The dirty data in the database is flushed into the disk .

9、 Thinking questions ： When performing an update operation , Why can't you modify the data on the disk ？

Okay , Today's article is drawing to a close , Let's think about another problem ：

Why? MySQL When updating data , It takes a lot of trouble to do so many things , Include buffer pool、redo log、undo log、binlog、 Transaction submission 、 Dirty data . Introduced a lot of concepts , There are complex processes and steps .

Why is it that he modifies the data in the disk most critically , To pass the IO Threads execute irregularly ？

Why doesn't he just execute every time SQL sentence , Just update the data in the disk ？