Table of contents
Introduction
MVCC (Multiversion Concurrency Control), that is, multi-version concurrency control technology, which enables most transaction engines that support row locks to no longer simply use row locks for database concurrency control, but instead combines database row locks with row locks. Combining multiple versions requires only a small overhead to achieve non-locking reading, thereby greatly improving the concurrency performance of the database system.
The purpose of MVCC is to manage multiple versions of the data being processed within a transaction when accessing (reading or writing) the database concurrently. This is used to avoid blocking of write operations, which may cause concurrency issues in read operations.
In mysql, when a transaction is created, a global transaction ID will be created by default. The following is a detailed description of inserting, modifying, deleting and querying data in the transaction:
In mysql data, there will be two fields: DB_TRX_ID and DB_ROLL_PT.
DB_TRX_ID is the global transaction ID number when data is added, and DB_ROLL_PT is the global transaction ID number when the row of data is deleted.
The following is an example of inserting data through a transaction:
insert
Inserting data rules: When inserting, add the current system global transaction ID number to the data row version number.
However, when new data is inserted through a transaction, the data row version number (DB_TRX_ID) is the current transaction version number, and the deletion version number is set to NULL.
delete data
Rule: Delete: Add the current system global transaction ID number to the deleted version number.
As shown in the figure above, if the data with ID 2 is deleted in the transaction, then the current deleted version number is added to the deleted version number of the data.
Revise
Rules: First copy the hit data row, then set the deleted version number of the original row data to the current global transaction ID, set the data row version number of the new row data to the current global transaction ID, and set the deleted version number to NULL.
As shown in the figure above, to change the data information with ID 1 in the transaction, first copy the metadata, then change the metadata deletion version number to the current transaction global version number, then insert new data, and set the data row version number to the current version number. .
Find
Rules: 1. Find the data row version number that is less than or equal to the current global transaction ID (this can confirm that the row read by the transaction already exists before the transaction starts, or was inserted or modified by the transaction itself), 2. Find the deleted version number that is NULL, Or an ID greater than the current transaction version number (that is, ensuring that the read row has not been deleted before this transaction is started)
From the above rules, we can see that when the deleted version number is not NULL, then the data exists. When the data in the data row version number is less than the transaction ID number of the currently executing transaction, then the data is Transactions are visible.
Therefore, when querying, the first one is to query the query data version number is less than the global transaction ID of the transaction, and the other is that its deletion version number is either NULL or greater than the current transaction global transaction ID. When it is NULL, it means that the entry The data exists. When it is greater than the global transaction ID of the transaction, it means that the data still exists when the transaction is executed.
MVCC handles concurrent transactions through such logic.
undo log and redo log
MySQL transaction log includes undo log and redo log
undo log
Undo log means that before the transaction starts and before any data is operated, the data to be operated is first backed up to a place (Undo Log).
When executing a transaction, we know that when the roll back command is called, the data will be restored. The principle used here is undo, which is also the principle to achieve transaction atomicity.
If an error occurs during transaction processing or the user executes the ROLLBACK statement, Mysql can use the backup in the Undo Log to restore the data to the state before the transaction started.
UndoLog is used to implement multi-version concurrency control in the Mysql innodb storage engine: before the transaction is submitted, Undo saves the version data before it is submitted. The data in Undo can be used as a snapshot of the old version of the data for other concurrent transactions to perform snapshot reading.
Before the transaction is executed, the old data will be backed up in the undo buffer in the cache. When the size of the backup data reaches a certain level, or when the backup data has not changed for a long time, an undo log will be generated and written to the disk.
redo log
redo log: redo log corresponds to undo log, which stores the latest data of transaction operations.
The redo log is mainly generated to achieve transaction durability. To prevent dirty pages from being written to the disk at the time of failure, when restarting the mysql service, redo is performed based on the redo log, thereby achieving the feature of persisting the transaction data that has not been written to the disk.
Among the policy settings in redo, one is the size of the log file, and the other is the size of the cache pool. Since the redo log data is meaningless once the transaction is committed and the data is persisted, the data in the redo log is written cyclically.
Specify the number of Redo log log files in the group innodb_log_files_in_group The default is 2
Specify the maximum storage size of each log file in Redo log innodb_log_file_size. The default is 48M.
Specify the buffer pool size of Redo log in cache/buffer innodb_log_buffer_size. The default is 16M.
Redo buffer strategy for persisting Redo log, Innodb_flush_log_at_trx_commit:
value 0, commit every second Redo buffer --> Redo log OS cache -->flush cache to disk [may lose transaction data within one second]
value 1, default value, every second Redo buffer is executed every time a transaction is submitted --> Redo log OS cache --> flush cache to disk [the safest, worst performance method] takes a value of 2. Redo buffer is executed every time a transaction is submitted --> Redo log OS cache and then every time Seconds to execute ->flush cache to disk operation