Brief description of redo logs and undo logs in MySQL

redo journal

• Random disk IO And order IO
  Random IO namely IO The address of the operation is random and discontinuous , The order IO Yes, the disk address of the operation is continuous
• Buffer Pool
  Buffer pool , That is, when a page of data is read for a wave of operations, it will not be immediately deleted or synchronously updated and modified to the disk , But kept in the so-called Buffer Pool in , The next time you use it, you don't have to read it again , Because the disk reading speed is too slow .Buffer Pool Space must be limited , In order to save the data that has been used , So I will maintain a LRU The linked list decides who goes and who stays , Also, according to a certain proportion LRU The linked list is divided into two parts , Some cache pages that are used very frequently are stored , Part of it is the opposite , As the program runs , The region to which a node belongs may also change . This will ensure that when buffer Pool Pages deleted when they are full are rarely accessed .
• Brushwork
  buffer pool The existence of means , After reading a page, if it is modified, it will not be refreshed to the disk in time . There is buffer pool Is dirty pages . There will be threads dedicated to cleaning the dirt , Or when the memory is not enough, a page will be deleted after cleaning , Or brush dirty in batches .
• redo journal
  buffer pool There is also a problem , When the data page is in buffer pool It is modified and synchronized to the disk for persistence without being dirty , If the system crashes, the modified part will be lost , It is also a problem to brush dirty every time a transaction is committed , Sometimes a page changes a byte , You have to brush the whole page （ One sql The tone is a transaction by default , Will assign a transaction ID）, Or one transaction modifies multiple pages , The speed of random disk is slow and there is too much useless waste of refresh .MySQL Inside redo Logs are used to keep records of changes , Then when the dirty pages are not flushed to disk synchronously ,redo Log is written to disk first , In this way, when the system collapses, it can pass redo Log recovery .redo The log is where the changes are recorded , For example, the address offset of the page in the table space number has been changed etc. , The advantage is , Because the log file is smaller than that 16k One page of data is many times smaller , And when designing , Logs are stored in a continuous space of fixed size , Input sequential disk operation is faster .buffer pool Full space will trigger dirty page refresh ,redo When the log space is full, it will also actively trigger the refresh of dirty pages . When the dirty page is refreshed, the corresponding redo The log space can be reused .
• When the log is written to disk
  redo Logs also have a buffer log buffer Dedicated to storing log cache , When log buffer When there is not enough space log buffer Of redo The logs are full log buffer About half of the total capacity , You need to refresh these logs to disk . Dirty pages may not be directly flushed to disk for persistence each time a transaction is committed , Instead, refresh the corresponding log file for persistence redo journal . There will also be a dedicated thread pair redo Log files are refreshed regularly . There is also page refresh when the server is shut down normally .

undo journal

• Business ID
  When one or more tones are executed when a transaction is started , The system will assign a unique transaction ID, Used to record changes undo journal , Because the query tone will not produce undo Therefore, there is no need to allocate logs to transactions ID The default is 0, The transaction will be assigned only when the modified tone is encountered ID. A transaction with query tone in front of it ID yes 0, The transaction will not be allocated until it is modified ID, Business ID The assignment of has a global variable control , When assigning a transaction ID The global variable is assigned as ID, Then the variable +1, That is to say, the first allocated transaction is guaranteed ID It will always be smaller than the post allocated transaction ID, This global variable is not infinite , When the maximum is reached, it will start from 0 Start . All in all , The purpose of this is to be able to do this according to the transaction ID Know the order of two things , This controls whether the version is readable by comparing the sequence of transactions in the later version chain .
• Record structure
  In a record, it will be hidden. When three columns are saved, one column will be added automatically ID Used for indexing , There are also two columns for transactions , There is a list of saved transactions ID, There is a column that holds rollback pointers , What's in it ID Is the transaction that changes the record ID, Insert is the transaction into which the record is inserted ID, Modification and deletion are also , The rollback pointer is the save point undo Of the pointer to the recorded address .
• undo journal
  Sometimes when a transaction is modified, it is generally accepted without committing and needs to be rolled back , That is to restore the original unchanged appearance ,MySQL Is to make a record of the transaction modification undo journal , Record the information before modification , For example, insert a record to record a record ID Just fine , Delete directly when rolling back , Update and delete the record to record all the information of the previous version , These log information will be stored in a table different from the data table type like data , It is also the same as the data page , So in redo The logs look the same page , Update dirty pages to disk , Generated by the same transaction undo The log will be linked into a undo chain . Inserted undo The log is useless after the transaction is committed and is deleted directly , Other logs will be in MVCC So it doesn't have to be deleted , There will be special threads Purge To determine whether it is still available , Delete when unavailable .Purge The operation will clone the oldest read_view, If the currently running transaction has no accessible undo The log will be marked for deletion .
• Version chain
  undo The log will produce an awesome thing , The so-called version chain . The hidden column of a record records the transactions that modify the record ID And point to undo Rollback pointer to the log , Then when the record is modified again , This information will be stored in undo A powerful version chain is formed in the log, that is, the figure
  
  Say that a record corresponds to a transaction ID value , It is this transaction that is modified to be like this , Then there is another one that points to the previous version undo Pointer to log , This is a version chain . The use is MVCC.
  Transferred to 《MySQ Transaction isolation level and MCVV》