Summary of three log knowledge points of MySQL

MySQL Summary of three log knowledge points

• binlog Binary log
• redolog Redo log
• undolog Rollback log

---

binlog

What is? binlog？

binlog yes MySQL Server Binary log of layer , Used to record MySQL All write operations performed . No matter what MySQL What storage engine to use , Write operations are recorded binlog.

binlog It's a logical log , New write operations are written by appending . If at present binlog File is too large. ,MySQL It will create a new one binlog File to record MySQL operation . Can be binlog Understood as a record of all Writeability sql Statement log .

• Logic log ： What can be simply understood as recording is sql sentence .
• Physical log ： because mysql Data is ultimately stored in the data page , Physical logging records data page changes .

binlog The strategy of disk brushing

about InnoDB For storage engines , Only when the transaction is committed will the data be recorded to biglog file . In the process of transaction execution and uncommitted , The data remains in memory .

binlog Three disk brushing strategies ：

• （1） It is up to the system to determine when to write to the disk .
• （2） Every time commit Write the data in the memory to binlog file .
• （3） Per submission N After a transaction , Will write the data in memory binlog file .

binlog Usage scenarios of

• Data recovery
• Master slave copy

---

redolog

What is? redolog？

redolog yes Innodb Store the logs provided by the engine , Be responsible for ensuring the persistence of transactions .

redolog The composition of

redolog It consists of two parts

• The log buffer (redo log buffer)
• Log files (redo log file)

Logs are buffered in memory , The log file is on disk .

MySQL When executing multiple statements over a period of time , These statements will be recorded to redolog In the log buffer of , Write the accumulated data in the log buffer to the log file at a subsequent point in time （ Brush set ）.

redolog The strategy of disk brushing

• redolog The process of brushing the disc ：
  In the operating system , User space (user space) In general, the buffer data under the following conditions cannot be directly written to the disk . therefore redo log buffer The data in must be written first os buffer（ Operating system buffer ）, Then call through the operating system fsync() Brush data to redo log file in .

• redolog Three disk brushing strategies

  • Delayed write ：
    When a transaction is committed, it will not immediately redo log buffer Submitted to the os buffer. But every second redo log buffer Data written in os buffer And call fsync() Brush data to redo log file in . This disk flushing strategy may lose nearly a second of data during downtime .

  • Write in real time , Delay brush ：
    Each transaction commit only writes data to os buffer in , Call every second fsync() Brush data to redo log file in .

  • Write in real time , Brush in real time ：
    Each transaction commit will redo log buffer Data write in os buffer, Call again fsync() Brush data to redo log file in . This disk flushing strategy will not lose any data .

redolog Record form of

redolog It's a physical log , Used to record changes to data pages .

redolog Don't like binlog Save all the data like that , It uses a fixed size , Log by writing circularly . The new record will overwrite the old record .

redolog Similar to a circular linked list , stay redolog There are two pointers in ：write pos、check point.write pos Responsible for recording current redolog Write location of , If there is new data , This data will be inserted into write pos Where it is .check point Represents the position of the brush plate , stay check point The previous data is the data that has been swiped and persisted .check point To write pos Between redo log Change record of data page to be dropped .write pos To check point The part between is redolog The free part of , You can record new records here .

---

undolog

What is? undolog？

undolog It's also Innodb Store the logs provided by the engine , Responsible for ensuring atomicity and MVCC Multi version concurrency control .

undolog Storage form of

undolog It's a logical log , The logical changes of the data are recorded , Can be undolog Simply understood as a person responsible for recording the opposite sql Statement log .
example ：
One INSERT sentence , There's a corresponding one DELETE Of the statement undolog.
One UPDATE sentence （xxx + 1）, It's the opposite UPDATE sentence （xxx - 1） Of undolog.
So when something goes wrong , By executing undolog To rollback to the data state before the transaction .

undolog Before the transaction starts , After the transaction is committed undolog It doesn't delete （Innodb The undolog Put it in the delete list , Later, through the background thread purge thread Recycling ）, Because users may need rollback Rollback operation , When you want to perform a rollback operation , from undolog buffer Read data from .

undolog Realize multi version concurrency control （MVCC）

undolog Saved version data before submission ,undolog The data in can be used as a snapshot of the old version of data for other concurrent transactions to read .

undolog The classification of

• insert undolog：
  insert undolog Will not be used for MVCC, So after the transaction is committed undolog Will be released directly .（ about INSERT Operation of the undolog, After the transaction is committed, it can be deleted , Because this is the first version, there is no need to store old data .）

• update undolog：
  update undolog Be used for MVCC. because UPDATE and DELETE Operation involves version control , So for UPDATE or DELETE Operations cannot be deleted directly after the transaction is committed undolog. Because the consistency of other transactions is still used undolog.update undolog Need to always store , It cannot be deleted until there is no snapshot transaction associated with it .（DELETE The operation will be marked with deletion first , Then from purge Thread to delete ）