People familiar with MySQL, InnoDB storage engine knows, as you know, Redo Log is one of the core innodb transaction logs, innodb after writing Redo Log will commit the transaction, rather than written to the Datafile. After innodb then asynchronously new transaction data asynchronously writes Datafile, really stored.
So innodb engine with redolog (log files) and buffer pool (buffer pool) later, why can simultaneously improve performance, but also to ensure that it does not lose data? What is the specific relationship between the Buffer Pool, Redo Log Datafile and it is .
In addition there are a lot Innodb concept, Dirty Page (dirty pages), LRU (least recently used), LSN (Log Sequence Number), Checkpoint (Checkpoint, checkpoint), and so on, these concepts are what works in Innodb in it?
Here to tell you through a map
Relations Buffer Pool, Redo Log and the Datafile
Principle 1 Innodb Figure
You can innodb transactions into the process as the process of writing an article. Innodb actually writing process and writing process we are very similar.
Just think, the leadership asked us to write an article, published in the forum. Then we thought of a great idea and decided to put the article, but there are other things on hand, short-lived fad never finish, it is feared after forgotten, leaders also waiting for us to answer, then we how would you do it? We will first outline a rough idea, and to outline some of the key details and records to the book, as a draft, then immediately tell the leadership of their own to write something, let it confirmed. Last night time, etc., and then pour the basis of the draft to the word discretionary sentence, written in artwork.
In this process, we use several key things:
Our brains, being used to temporarily remember our ideas
Draft, we need to ensure that the draft will not put ideas and critical details forgotten
Artwork, which is what we ultimately output
With these things, we can not only make sure we do not miss a beautiful article, can quickly tell the leadership of their own will be able to get this thing.
Innodb also used the fact that a few key things:
Buffer Pool: that our brains
Transaction Log: that our draft
Datafile: is our artwork
Just follow the process before writing the article, to write the entire transaction, not only to ensure that no data is lost, and can respond quickly.
Write operation is a transaction, innodb transaction data is first written to the Buffer Pool and the transaction log, which is memorized in the brain, and wrote drafts. You can then commit the transaction, the response to the client. After the innodb "have time", the data asynchronously written formally written from the Buffer Pool, or the transaction log to Datafile form "artwork."
Which, innodb transaction logs to ensure this "draft" will be able to restore the artwork nondestructive, it can not take up too much space, the transaction log needs to have the following characteristics:
The transaction log must save all the data content to be written
The contents of the transaction log only new transaction log is added in the final, and not to modify the previous
Once the transaction data is written to the datafile, the transaction log "draft" can be deleted
By the above three features, we can see that, before forming the "artwork", "draft" is not deleted; the same time, "Drafts" space can be recycled; and finally, as long as the "draft" in, we must be able to write "artwork."
There is also to be noted, that Recovery process. That is, if the formation before the "artwork" Crash database, and we need to restart the whole process, server, or even only to copy the data to another server to recover. This time, the transaction log "draft" to play its biggest role - data recovery. This is also a problem that we often occur in working life - things to forget - is very similar.
Buffer Pool is essentially a data structure stored in memory, the memory and the human brain, is "forgetful" of. When the database Crash, Data Buffer Pool in the most likely "ashes" of the. Therefore, the transaction log as we close the "Notepad", it is our memory, save it as a "draft", when we forget that when you can open, his memory back in retrospect.
(This is the image
）
FIG recovery logic 2
LSN and Checkpoint
The above describes the case of a write transaction, and the database in use, transactions are continuous, according to the above innodb logic, write "draft" and write "artwork" at the speed and progress of the vast majority of cases are not the same.
To continue the example, "writing articles" above, if our article is very long day, I will never finish, while others have to work during the day, we can only record the draft, only to go back at night to continue to write artwork. Then we face a problem: where we wrote yesterday.
The most common way is to draft every night to control what content and artwork content, in order to determine where to write, but that take longer, because the artwork may contain a lot of gorgeous statement, we need to think about to compare the content.
Another, more simple way, that is, after every night finished artwork, we make a mark on the draft, marking the last one was written down for the content of the artwork, so the next night, we can from the back of the tag a start, continue to write our artwork, without the need to compare the content.
The second method is clearly higher efficiency, and there is no additional risk. Therefore innodb on the use of this approach. LSN is the number of each record on the draft, marking down every night we wrote the last record number of artwork, the tag number is Checkpoint. Innodb According to this checkpoint, you can quickly know where the last replay, but can also put a draft before this number, all deleted.