This article is to introduce MySQL database storage engine InnoDB redo log roaming
00 - Undo Log
Undo Log is to achieve transactional atomicity in the MySQL database InnoDB storage engine, also used to Undo Log multi-version concurrency control (abbreviation: MVCC).
- the atomicity of transactions (Atomicity)
all operations in the transaction, either completed or no operation, not only part of the operation. If occurs during the execution of
an error, the state before the start of the transaction to rollback (Rollback) to, as this transaction never performed.
- Principle
Undo Log principle is very simple, in order to meet the atomicity of transactions, prior to the operation of any data, back up data to a first place
(this place to store backup data referred to Undo Log). Then modifying the data. If an error or a user performs a
ROLLBACK statement, the system can use the backup Undo Log in to restore the data to its state before the transaction began.
In addition to guarantee the atomicity of transactions, Undo Log can be used to assist complete the transaction persistence.
- durability of transactions (Durability)
transaction, once completed, the transaction is saved to the database all changes made to the database will be long-lasting. To ensure durability, the database
data recording system will be fully modified to persistent storage.
- atomicity of transactions and persistence with Undo Log simplification
Suppose A, B two data values 1, 2, respectively.
A. transaction begins.
B. A = 1 to the recording undo log.
C. Review. 3 = A.
D. B = 2 to the recording undo log.
E. modification. 4 = B.
F. The undo log is written to disk.
G. writes data to disk.
H. transaction commits
There is an implicit precondition: 'data is read into memory first, and then modify the data in memory, and finally write data back to disk'.
At the same time we have been able to guarantee the atomicity and persistence, because of the following characteristics:
A. Before updating the data records Undo log.
B. In order to ensure durability, the data must be written to disk until the transaction commits. As long as the transaction successfully submitted, the data must have been persistent.
C. Undo log must precede the data persisted to disk. If the system crashes in between the G, H, undo log is complete,
can be used to roll back the transaction.
D. If in the AF between the system crashes, since there is no data persisted to disk. Therefore, the data on the disk or remain in the state before the transaction began.
Defects: before each transaction commits and Undo Log data is written to disk, this will cause a lot of disk IO, and therefore very low performance.
If the data can be cached for some time, it can reduce IO to improve performance. But this will lose durability of transactions. Therefore, the introduction of another
Zhong mechanism to achieve a lasting, that is Redo Log.
01 – Redo Log
- Principle
and Undo Log In contrast, Redo Log record new data is backed up. Before a transaction is committed, as long as the Redo Log persistence you can,
do not need the data persistence. When the system crashes, although the data are not persistent, but Redo Log has persisted. The system can be based on
the content of Redo Log in to restore all data to date.
- Undo + Redo transaction process simplified
Suppose A, B two data values 1, 2, respectively.
A. transaction begins.
B. recording log A = 1 to Use the undo.
C. Review. 3 = A.
D. A recording = 3 to redo log.
E. B = 2 to record log Use the undo.
F. Review B = 4.
G. record B = 4 to redo log.
H. written to disk redo log.
I. transaction commits
- Undo + features Redo affairs
A. In order to ensure long-lasting, it must be Redo Log persist until the transaction commits.
B. Data does not need to be written to disk before the transaction commits, but cached in memory.
Persistent C. Redo Log guarantee transaction.
Atomic D. Undo Log guarantee transaction.
E. There is an implicit characteristic data must be written later than the redo log persistent storage.
- IO performance
Undo + Redo the design of the main considerations is to enhance IO performance. Although by caching data, reducing the IO write data.
But introduces a new IO, the IO-write Redo Log. If the Redo Log IO performance is not good, it can not serve the purpose of improving performance.
In order to ensure Redo Log can have a better IO performance, Redo Log InnoDB design has the following characteristics:
A. keep on a contiguous storage space in the Redo Log. So it will be fully allocated space in the log file when the system first starts.
Additionally recording a sequential manner Redo Log, to improve performance by sequentially IO.
B. Batch written to the log. Log not directly write to a file, but the first written redo log buffer. When you need to refresh the log to disk
(such as transaction commits), is written to disk along with many of the log.
C. concurrent transactions Redo Log shared storage space their execution order Redo log statement, are alternately recorded together,
to reduce the space occupied by the log. For example, content recorded Redo Log might look like this:
Record 1: <trx1, insert ...>
Record 2: <trx2, update ...>
Record 3: <trx1, delete ...>
record 4: <trx3, update ...>
Record 5: <TRX2, INSERT ...>
D. C of reasons, when a transaction is written to disk Redo log when will the other uncommitted transaction log is written to disk.
E. Redo Log carried out only on the order of an additional operation, when a transaction needs to roll back, it will not be the Redo Log records from
deleted Redo Log in.
02 - recovery (Recovery)
- recovery policy
affairs said before the uncommitted and roll back the transaction will be recorded Redo Log, therefore during recovery, these transactions should be special
treatment there are two different recovery strategies:
A. When the recovery, just redo the transaction has been submitted.
B. When the recovery, redo all transactions including uncommitted transactions and roll back the transaction. Then roll back those by Undo Log
uncommitted transactions.
- recovery mechanism InnoDB storage engine of
MySQL database storage engine InnoDB uses a strategy B, the recovery mechanism InnoDB storage engine have the following characteristics:
A. When redo Redo Log, does not care transactional. Recovery, no BEGIN, nor COMMIT, ROLLBACK behavior.
Each log is not concerned about what matters. Although the transaction ID and other transaction-related content will be recorded in the Redo Log, content just to be treated as
part of the data to be operated.
B. Use B To Undo Log strategies must be persistent and must be written before the Redo Log corresponding Undo Log written to disk.
Undo and Redo Log this association, such that persistence becomes complicated. In order to reduce complexity, InnoDB considered the Undo Log
data, so that the recording operation will Undo Log records in the redo log. So as you can undo log data as cached,
but not written to disk before the redo log.
Redo operations comprising Undo Log Log, looks like this:
Record 1: <trx1, Undo log insert <undo_insert ... >>
Record 2: <trx1, insert ...>
Record 3: <trx2, Undo log insert <undo_update ...> >
record 4: <trx2, update ...>
record 5: <trx3, Undo log insert <undo_delete ... >>
record. 6: <TRX3, Delete ...>
C. Here, there is a problem is not clear. Since Redo not transactional, it would mean that re-executes the transaction to be rolled back?
Indeed it is. Meanwhile Innodb will also operate when the transaction is rolled back also recorded in the redo log in. The rollback operation is essentially
modify the data, and therefore rollback operations on data also recorded in the Redo Log.
Redo Log rollback of a transaction, it looks like this:
Record 1: <trx1, Undo log insert <undo_insert ... >>
Record 2: <trx1, insert A ... >
record 3: <trx1, Undo log insert < undo_update ... >>
record 4: <trx1, update B ... >
record 5: <trx1, Undo log insert <undo_delete ... >>
record 6: <trx1, delete C ... >
record 7: <trx1, insert C>
record 8: <trx1, update B to old value >
record 9: <trx1, delete a>
a transaction to be rolled back in a recovery operation is to redo then undo, it will not destroy data consistency.
- InnoDB storage engine related functions
Redo: recv_recovery_from_checkpoint_start ()
Undo: recv_recovery_rollback_active ()
Undo the Log of Redo Log: trx_undof_page_add_undo_rec_log ()
Reprinted to: http://www.mysqlops.com/2012/04/06/innodb-log1.html