Four characteristics Affairs
Atomicity (Atomicity): Atomic refers to the entire database transaction is indivisible unit of work. All database operations in the transaction, either all submitted successfully, or all fail rolled back.
Consistency (Consistency): transition from the state database is always a consistent state to another consistent.
Isolation (Isolation): transaction isolation requirements for each read and write transactions to the operation target object can be separated from each other transaction, i.e., before submitting the transaction is not visible to other transactions.
Persistent (Durability): Once the transaction is committed, the result is permanent, even if downtime or other failures, databases, data can be restored.
Concurrent consistency
- Modify loss
- Dirty read: read uncommitted data
- Non-repeatable read: read data submitted; the same conditions, the first and second read values are different.
- Phantom read: the same conditions, the first and second read out of the record differently.
Isolation Levels
READ UNCOMMITTED (read uncommitted): Modify the transaction, even if not submitted, other transactions are also visible. Anything not locked.
READ COMMITTED (Read Committed): a firm to do a transaction can only read the already submitted. In other words, a firm changes made prior to submission of other transactions is not visible. Read data is not locked, but the data write, modify, and delete all locked.
REPEATABLE READ (Repeatable Read): to ensure the same reading result data multiple times in the same transaction are the same. MVCC mechanism for data becomes repeatable read.
SERIALIZABLE (serialization): Force transaction serial execution. All operations plus pessimistic locking. Reading shared locks, plus exclusive write locks.
Redo log
Redo log consists of two parts: the redo log buffer memory and redo log file.
When the transaction commits, it must first log all transactions are written to the redo logs for persistence. After each redo log buffer is written redo log file, InnoDB storage engine needs to be called once fsync operation to ensure that the log is written to disk. Since the fsync operation depends on the disk, so disk performance determines the performance of the transaction is committed.
Innodb_flush_log_at_trx_commit parameters used to control the redo log flushed to disk strategy. The default parameter value is 1, you must call fsync operation once the transaction commits. Parameter is not written redo log operation 0 for the transaction commits, and for writing the redo log once per second in the master thread, and perform fsync operations. 2 shows the parameters for the redo log write transaction commit redo log files, but only written to the cache, without fsync operation.
Undo log
If the transaction performed by the user or the statement fails for some reason, or if a user with a request to roll back ROLLBACK statement, you can use the undo information to roll back the data. stored in the internal database undo undo segment (segment undo) in.
When the InnoDB storage engine to roll back, it's actually doing is the opposite of the previous work. For each UPDATE, will perform a reverse UPDATE, the row will be put before the amendment back. If INSERT, performs DELETE, and vice versa empathy. So, undo log is logical rather than physical recovery. Data structures, and the page itself may be quite different after the rollback. You can not roll back to a page look like the beginning of a transaction, because it will affect other transactions ongoing work.
The locks InnoDB
Row-level locking
- Share locks (S Lock, Shared), allows transactions to read a line of data
- Exclusive lock (X Lock, Exclusive), allowing the transaction to update or delete a row of data
transaction data objects A plus X lock, you can read and update the A. Other transactions during the lock can not A plus any lock.
A data object of a transaction plus S locks, read operations can be A, but the operation can not be updated. During the other transactions can lock to lock A plus S, but can not add X lock.
Compatible relations
| - | X | S |
|---|---|---|
| X | NO | NO |
| S | NO | YES |
Table-level lock: Lock intention (Intention Lock)
- Intention shared lock (IS Lock), transaction wants to get a table in a few lines of a shared lock
- Intent exclusive locks (IX Lock), a transaction large column InnoDB how to ensure that the four characteristics of the transaction you want to get a table row a few lines of his lock
IS is compatible between any / IX locks, because they just want to express to the table lock, rather than a true lock.
S lock is only compatible with S IS lock and lock, that transaction T wants to rows of data S plus lock, other transactions can lock on the table have been obtained S or rows in the table.
Compatible relations
| - | X | IX | S | IS |
|---|---|---|---|---|
| X | NO | NO | NO | NO |
| IX | NO | YES | NO | YES |
| S | NO | NO | YES | YES |
| IS | NO | YES | YES | YES |
Consistent non-locking read
Consistent non-locking read: If a record is added to the X lock, other transactions from reading this record, do not wait for the release of the lock on the row, InnoDB storage engine to read a snapshot of the data line.
A line record may have more than a snapshot of the data, this technique generally referred to as multi-line version of the technology. The resulting concurrency control, called multi-version concurrency control (Multi Version Concurrency Control, MVCC).
MVCC: add a version identifier for the data in the database table version based solutions, in general, is achieved by adding a "version" database table fields. When reading out the data, read together this version, when after the update, this version number plus one. At this time, the data will be submitted to the version with the current version of the database table data corresponding to the information recorded for comparison, data submitted is greater than the version number of the database table if the current version number, the update them, or that the data is expired.
READ COMMITTED transaction isolation level, snapshot data for non-uniformity always read the latest reading a snapshot of the data is locked row.
REPEATABLE READ transaction isolation level, snapshot data for non-consistency always reads read data line version of the transaction began.
Lock read consistency
Show the reading operation for locking the database.
SELECT … FOR UPDATE
SELECT … LOCK IN SHARE MODE
Three algorithms row lock
InnoDB storage engine, there are three rows of lock algorithm.
- Record Lock: lock on a single row record. Lock the index record (if no index table built, using implicit primary key lock)
- Gap Lock: gap lock, a lock range, but does not contain the records themselves.
- Next-Key Lock: a Gap Lock + Record Lock, a lock range, and the locking records themselves (before and after the opening and closing section).
Next-Key Locking using InnoDB query, solve the phantom reads.
How InnoDB guarantee atomicity (Atomicity)?
In a transaction in any of the data changes will write a undo log, and then modify the data, and if an error occurs, the storage engine will use undo log backup data is restored to the state before the transaction began.
How InnoDB ensure consistency (Consistency)?
Atomicity and isolation transactions to ensure data consistency
How to ensure the InnoDB isolation (Isolation)?
InnoDB is the default isolation level REPEATABLE READ + Next-Key Locking, ensure the isolation of the database, concurrency consistency problem does not occur, and theoretically more efficient than SERIALIZABLE isolation level.
How InnoDB ensure persistent (Durability)?
InnoDB storage engine regardless of whether the normal shutdown last time the database is running on startup, will try to resume operation by redo log.
References:
- "MySQL Inside: InnoDB storage engine (Version 2)" the Jiangcheng Yao
- Talk about MySQL InnoDB storage engine transactional ACID properties