EDITORIAL
Mentioned InnoDB, MVCC when the concepts, we often hear redo log and undo log name, then what role is it both? In fact, the two are not unique transaction operations, will also record when the index update redo/undo log, even recording undo log will be recorded redo log, and this article focuses on affairs redo/undo log.
redo, undo log Past and Present
Suppose now only undo log mechanism.
In order to ensure that before the transaction commits unexpected downtime is not lost update, be sure you want to undo log brush to disk, but it can cause multiple disks IO, but considering the log file is written sequentially, better performance. After the transaction commits, we need to dirty pages in memory to disk immediately synchronize data file, which can cause random disk at least once IO, affect performance.
Therefore, database designers to think, if the transaction commits, dirty page data can be cached in memory for some time, without the need to be synchronized to a disk file immediately, you can merge multiple random IO to improve performance. But this will lose durability of transactions, because if the transaction has been submitted, the data still goes down in the memory after the restart because the only undo log data to be submitted can not be recovered.
Therefore, designers have introduced another mechanism to achieve a lasting, that is redo log. Before a transaction is committed, as long as the redo log persistent, you do not need the data persistence. When the system is down, although the data is not enough time to brush back to disk, but redo log has persisted, the system can be based on redo log content, all data will be restored to the latest state.
What is the redo log
MySQL Uses a lot of memory Cache area for data modification operations will first directly modify the memory Page, but these pages are not immediately synchronized disk, then the data is already in memory and on disk is inconsistent, and we call this Page dirty page . Imagine this time if the database is down, this part of the memory the modified data record is lost, there is no way to recover after the restart.
Therefore, in order to ensure the security of data, modifying memory Page after InnoDB write redo log, because redo log a written order, but the order read and write speed is much larger than the well-known disk random read and write, so this part of the log write performance impact on small . Then, InnoDB it will be submitted prior to the transaction will redo log be saved to disk. Referred to herein redo log is logical and not physical log log record that data page physical modification, instead of a row or a few rows how how to modify it to restore the data of the physical page after submission (to restore the data page, and only be restored to the position of the last commit).
When the database unexpected restart, based on redo log data recovery, if redo log there is a transaction is committed, the transaction to modify the data submitted.
What is the undo log
And redo log different, undo log usually logical logs recorded according to each recording line. For example, when DELETE during a record, undo log the record will be a corresponding INSERT record, and vice versa when UPDTAE a record, which record corresponds to a reverse UPDATE record.
Distributed Transaction Seata the GTS model is implemented so, but this process on the client code, and support required by the SQL type
When the data is modified in addition to recording redo log it is also recorded undo logby undo log can achieve transaction rollback on the one hand, on the other hand can undo log be traced back to a particular version of the data, to achieve MVCC the function.
Alone undo log okay?
Only undo log in the case must be guaranteed before the transaction commits, dirty pages must brush back to disk, or otherwise revise down this part of the data in memory is lost, destroyed persistence, but as mentioned above, this approach is too performance poor, must be improved.
Alone redo log okay?
Only redo log in case you can not brush dirty before the transaction commits, we assume that there is a large amount of data to update a large transaction, part of the update finished part must brush dirty pages to disk and then load other data into memory operation, this time to half if the update down, then there is a part of the database data in the old part of the new data, but the transaction has not submitted, and therefore should be rolled back, only redo log unable to complete the case.
redo / undo log persistence
redo log It consists of two parts, part of memory redo log buffer, part of which is volatile, restart gone; the second is on the disk redo log file, is persistent.
InnoDB Through force log at commit to achieve technical matters persistence characteristics. In order to ensure that each redo log can be written to a log file on disk, each time the memory redo log buffer will be called once when synchronizing disk contents fsync.
OS, write and fsync are different operations, we believe that everything will be fine to call the write data to the disk must, in fact, not necessarily, but normally write to the disk IO buffer zone controlled by the OS when fsync, forced by the program here call log to ensure that certain brush to disk
Reference material
redo / undo log, binlog and explain the difference
Detailed analysis of the MySQL transaction logs (redo log and undo log)
