MySQL - MariaDB - ClickHouse - InnoDB - Galera Cluster - MySQL Support - MariaDB Support - MySQL Consulting - MariaDB Consulting - MySQL Remote DBA - MariaDB Remote DBA - Emergency DBA Support - Remote DBA - Database Migration - PostgreSQL - PostgreSQL Consulting - PostgreSQL Support - PostgreSQL Remote DBA

InnoDB Transaction Isolation Levels

Shiv Iyer — Wed, 21 Feb 2018 09:49:00 +0000

InnoDB Transaction Isolation Levels

To maintain transactional consistency in the database systems, It follows ACID properties. ACID stands for Atomicity, Consistency, Isolation and Durability, The isolation levels determines how transaction must be isolated from the data modifications made by any other transactions with in the database system, Below I have explained transaction isolation level in detail :

Dirty Read – The “Dirty Read” happens when a transaction reads data which is not yet committed so technically there is no isolation level in place. For example, Let’s consider transaction T1 updates a row and has not yet committed. meanwhile the transaction T2 reads the uncommitted updated row . If ever transaction T1 rollbacks, transaction T2 would have read the data that is considered never to have never existed . To conclude, we can’t consider such systems as transactional systems !

Non Repeatable Read – “Non Repeatable Read” happens when a transaction reads same row twice and reports different data each time . For example, Consider transaction T1 reads a data and another transaction T2 updates the same data and commit, If again transaction T1 rereads the same data, It will report a different data .

Phantom Read – “Phantom Read” occurs when two same queries are executed, but rows retrieved by the two are different . Let me explain with a example, Transaction T1 is reading data on a specific SELECT criteria by continuously executing the same query and Transaction T2 is continuously inserting data matching to the SELECT criteria of Transaction T1 . When Transaction T1 re-executes the same query, It will retrieve different set of rows this time

To address these challenges InnoDB have come-up with different isolation levels – Repeatable Read, Read Committed, Read Uncommitted and Serializable

Repeatable Read

We can’t see ANY DATA from other transaction until we are actually done with our transaction, Theoretically (and in many other database systems) this kind of an isolation level may cause phantom reads, but in InnoDB it’s not possible .

Read Committed

In Read Committed isolation level, You cannot see the data in Transaction T1 from Transaction T2 until it is committed in the Transaction T1, Note that Transaction T1 won’t see the data until it has committed it’s own data. So dirty reads are not possible in Read Committed isolation level but Non-Repeatable Reads and Phantom Reads are still possible .

Read Uncommitted

There is no isolation in Read Uncommitted transaction isolation level, Transaction T1 will see all the uncommitted transactions from Transaction T2, This means when Transaction T2 rollback, all data will be rolled back to what it was just like before start in Transaction T1 , This is called dirty read .

Secondly, when transaction T1 changes data and commits that data, transaction T2 still sees that data as changed during it transaction. Basically: it gets different results with the same query, which is called a non-repeatable read and allthough this is similar as a dirty read, we categorize it differently.

Finally, it is possible that transaction T1 inserts new rows in its transaction. Those records are called phantom rows and of course can dissappear when the transaction does a rollback.

Serializable

Serializable locks all records that a transaction select for all the other transactions. It means that when a transaction updates a record, it becomes impossible for others to select that record. It’s a great way to make absolutely sure that no transaction overwrites the actions of other transactions, but it comes with the costs of lots of record locking.

Examples

I have explained below the MySQL isolation levels :

create database isolate;

use isolate;

create table tab1
( col1 int,
col2 int);

insert into tab1
values (2,4);

insert into tab1 
values (3,5);

insert into tab1 
values (6,8);

Read Uncommitted

Transaction T1

select @@tx_isolation;


+-----------------+
| @@tx_isolation  |
+-----------------+
| REPEATABLE-READ |
+-----------------+

Transaction T2

select @@tx_isolation;


+-----------------+
| @@tx_isolation  |
+-----------------+
| REPEATABLE-READ |
+-----------------+

Transaction T1

start transaction;

Query OK, 0 rows affected (0.00 sec)

Transaction T2

set session transaction isolation level read uncommitted;

Query OK, 0 rows affected (0.00 sec)

start transaction;

Query OK, 0 rows affected (0.00 sec)

Transaction T1

select * from tab1;

+------+------+
| col1 | col2 |
+------+------+
|    2 |    4 |
|    3 |    5 |
|    6 |    8 |
+------+------+
3 rows in set (0.00 sec)

Transaction T2

select * from tab1;

+------+------+
| col1 | col2 |
+------+------+
|    2 |    4 |
|    3 |    5 |
|    6 |    8 |
+------+------+
3 rows in set (0.00 sec)

Transaction T1

update tab1 set col2 = col2 + 1;

Query OK, 3 rows affected (0.00 sec)
Rows matched: 3  Changed: 3  Warnings: 0

Transaction T2 (dirty read)

select * from tab1;

+------+------+

| col1 | col2 |

+------+------+

|    2 |    5 |

|    3 |    6 | 

|    6 |    9 |

+------+------+

3 rows in set (0.00 sec)

Transaction T1

rollback;

Query OK, 0 rows affected (0.01 sec)

Transaction T2

select * from tab1;

+------+------+

| col1 | col2 |

+------+------+

|   2 |     4 |

|   3 |     5 |

|   6 |     8 |

+------+------+

3 rows in set (0.00 sec)

commit;

Query OK, 0 rows affected (0.00 sec)

As you can see it’s possible for Transaction T2 to see the data that was modified by Transaction T1. However, after the rollback of Transaction T1, the data is reverted back.

Read Committed

Transaction T1

start transaction;

Query OK, 0 rows affected (0.00 sec)

Transaction T2

set session transaction isolation level read committed;

Query OK, 0 rows affected (0.00 sec)

start transaction;

Query OK, 0 rows affected (0.00 sec)

Transaction T1

select * from tab1;

+------+------+

| col1 | col2 |

+------+------+

|   2  |     4 |

|    3 |     5 |

|    6 |     8 |

+------+------+

3 rows in set (0.00 sec)

Transaction T2

select * from tab1;

+------+------+

| col1 | col2 |

+------+------+

|    2 |    4 |

|    3 |    5 |

|    6 |    8 |

+------+------+

3 rows in set (0.00 sec)

Transaction T1

update tab1 set col2 = col1 + 3;

Query OK, 3 rows affected (0.00 sec)

Rows matched: 3  Changed: 3  Warnings: 0

Transaction T2 (no dirty reads)

select * from tab1;

+------+------+

| col1 | col2 |

+------+------+

|    2 |    4 |

|    3 |    5 |

|    6 |    8 |

+------+------+

3 rows in set (0.00 sec)

Transaction T1

commit;

Query OK, 0 rows affected (0.00 sec)

Transaction T2

select * from tab1;

+------+------+

| col1 | col2 |

+------+------+

|    2 |    5 |

|    3 |    6 |

|    6 |    9 |

+------+------+

3 rows in set (0.00 sec)

This level shows the dirty read is not possible, but after the commit of Transaction T1, the data is available to Transaction T2 .

Repeatable Read

Transaction T1

start transaction;

Query OK, 0 rows affected (0.00 sec)

Transaction T2

set session transaction isolation level repeatable read;

Query OK, 0 rows affected (0.00 sec)

start transaction;

Query OK, 0 rows affected (0.00 sec)

Transaction T1

select * from tab1;

+------+------+

| col1 | col2 |

+------+------+

|    2 |    5 |

|    3 |    6 |

|    6 |    9 |

+------+------+

3 rows in set (0.00 sec)

Transaction T2

select * from tab1;

+------+------+

| col1 | col2 |

+------+------+

|   2 |     5 |

|   3 |    6 |

|   6 |    9 |

+------+------+

3 rows in set (0.00 sec)

Transaction T1

update tab1 set col2 = col1 + 10;

Query OK, 3 rows affected (0.01 sec)

Rows matched: 3  Changed: 3  Warnings: 0

select * from tab1;

+------+------+

| col1 | col2 |

+------+------+

|    2 |    12 |

|    3 |    13 |

|    6 |    16 |

+------+------+

3 rows in set (0.00 sec)

Transaction T2

select * from tab1;

+------+------+

| col1 | col2 |

+------+------+

|    2 |    5 |

|    3 |    6 |

|    6 |    9 |

+------+------+

Transaction T1

commit;

Query OK, 0 rows affected (0.01 sec)

Transaction T2

select * from tab1;

+------+------+

| col1 | col2 |

+------+------+

|    2 |    5 |

|    3 |    6 |

|    6 |    9 |

+------+------+

commit;

Query OK, 0 rows affected (0.00 sec)

select * from tab1;

+------+------+

| col1 | col2 |

+------+------+

|   2 |    12 |

|   3 |    13 |

|   6 |    16 |

+------+------+

3 rows in set (0.00 sec)

After the commit of Transaction T1 we still see the unchanged data. Only after a commit (or rollback) from Transaction T2 we see that the data has changed.

Serializable

Transaction T1

start transaction;

Query OK, 0 rows affected (0.00 sec)

Transaction T2

set session transaction isolation level serializable;

Query OK, 0 rows affected (0.00 sec)

start transaction;

Query OK, 0 rows affected (0.00 sec)

Transaction T1

select * from tab1;

+------+------+

| col1 | col2 |

+------+------+

|   2  |    17 |

|   3  |  18   |

|    6 |    21 |

+------+------+

3 rows in set (0.00 sec)

update tab1 set col2 = col2 + 5;  

Query OK, 3 rows affected (0.00 sec)

Rows matched: 3 changed: 3  Warnings: 0

Transaction T2 (locked)

select * from tab1;

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

Transaction T1

commit;

Query OK, 0 rows affected (0.01 sec)

Transaction T2

select * from tab1;

+------+------+

| col1 | col2 |

+------+------+

|    2 |    22 |

|    3 |    23 |

|    6 |    26 |

+------+------+

3 rows in set (0.00 sec)

You see that after we have done an update we cannot select the data in the other transaction anymore. We have to wait until Transaction T1 commits or rollbacks the transaction.

The post InnoDB Transaction Isolation Levels appeared first on The WebScale Database Infrastructure Operations Experts.

How InnoDB handles locks ?

Shiv Iyer — Mon, 12 Feb 2018 17:13:18 +0000

The database locks exist to protect shared resources or objects, This could be Tables, Data Rows, Data Blocks, Cached Items, Connections or even the Entire Database Systems . The locks ensure reliable transaction that adhere to ACID properties of transactional systems . ACID is an acronym that stands for Atomicity, Consistency, Isolation and Durability . In this post I have explained how InnoDB locks works.

What are the different kinds of locking supported in InnoDB (MySQL 5.7) ?

Shared and Exclusive Locks
Intention Locks
Record Locks
Gap Locks
Next-Key Locks
Insert Intention Locks
AUTO-INC Locks
Predicate Locks for Spatial Indexes

Row-level locking in InnoDB
InnoDB handles row-level locking with types of locks, shared (S) locks and exclusive (X) locks . The shared (S) lock allows transaction that holds the lock to read a row and exclusive (X) lock permits the transaction that holds the lock to update or delete a row . I have explained this below with an example

Consider transactions T1 and T2 . Transaction T1 is holding shared (S) lock on row R1, Let’s see how MySQL handles locks now when Transaction T2 request for lock on same row R1 :

A request for shared (S) lock from T2 will be granted immediately so now both transactions T1 and T2 are holding an S lock on R1

What if Transaction T2 is holding an exclusive (X) lock on row R1 ? Then Transaction T2 have to wait for an lock of either type – shared (S) locks and exclusive (X) locks , So Transaction T2 has to wait for Transaction T1 to release it’s lock on row R1 .

Intention Locks
InnoDB permits coexistence of both row locks and table locks. Intention locks in InnoDB are table-level locks that indicates which type of lock (shared or exclusive) a transaction needs in the future for a row in a table . We have two types of intention locks :

Intention shared lock (IS) indicates that a transaction intends to set a shared (S) lock on individual rows of a table

Intention exclusive lock (IX) indicates that a transaction intends to set an exclusive (X) lock on individual rows of a table

In Intention Locks, Before a transaction can acquire a shared lock on row of a table, It must acquire either Intention shared lock (IS) or Intention exclusive lock (IX) on the table and to acquire an exclusive lock on rows of a table, It must first acquire an Intention exclusive lock (IX) lock on the table . The lock is granted to a requesting transaction only if it is compatible with existing lock, not definitely if it conflicts with existing locks (to avoid possible deadlocks) . The only purpose of intention locks is to show some transaction is locking a row or going to lock a row of a table . You can monitor transaction data of an intention lock with SHOW ENGINE INNODB STATUS .

Record Locks

A record lock is a lock on index record . For example, SELECT C1 FROM T1 WHERE C1=50 FOR UPDATE; prevents any other transactions from inserting or updating or deleting rows where T1.C1 is 50 . Records locks always locks index records, If your table don’t have indexes then InnoDB creates hidden clustered index and use that index for record locking . You can monitor transaction data for record locking with SHOW ENGINE INNODB STATUS .

Gap Locks

A gap lock is a lock on a gap between index records . For example, SELECT C1 FROM T1 WHERE C1 BETWEEN 30 and 60 FOR UPDATE ; In this case, the gaps between all existing values in the range are locked . Gap locks are actually the tradeoffs between performance and concurrency .

Next-Key Locks

In Next-Key Locks InnoDB performs row-level locking in such a way that when it searches or scans a table index, It sets shared or exclusive locks on the index records it encounters . In short, A next-key lock is a combination of a record lock on the index record and gap lock on the gap before the index record . Thus, the row-level locks are actually index-record locks. A next-key lock on an index record also affects the “gap” before that index record. That is, a next-key lock is an index-record lock plus a gap lock on the gap preceding the index record. If one session has a shared or exclusive lock on record R1 in an index, another session cannot insert a new index record in the gap immediately before R1 in the index order .

Insert Intention Locks

An insert intention locks are an type of gap lock set by INSERT operations prior to row insertion . These lock signals intent to insert in such a way that multiple transactions inserting into the same index gap need not wait for each other if they are not inserting at the same position within the gap. Let’s consider that there are index records with values of 15 and 20 . Separate transactions that attempt to insert values of 17 and 19 respectively, each lock gap between 15 and 20 with insert intention locks prior to obtaining the exclusive lock on the inserted row, but do not block each because the rows are nonconflicting .

AUTO-INC Locks

An AUTO-INC lock is table-level lock happens on transactions inserting to table with AUTO_INCREMENT columns . In the simplest case, if one transaction is inserting values into the table, any other transactions must wait to do their own inserts into that table, so that rows inserted by the first transaction receive consecutive primary key values. The innodb_autoinc_lock_mode configuration option controls the algorithm used for auto-increment locking . It allows you to choose the trade off between predictable sequences of auto-increment values and concurrency for insert-operations .

Predicate Locks for Spatial Indexes

InnoDB supports SPATIAL indexing of columns containing spacial columns . To enable support of isolation levels for tables with SPATIAL indexes, InnoDB uses predicate locks . A SPATIAL index contains minimum bounding rectangle (MBR) values, so InnoDB enforces consistent read on the index by setting a predicate lock on MBR values used for a query, Else transactions cannot insert or modify a row that would match the query condition

The post How InnoDB handles locks ? appeared first on The WebScale Database Infrastructure Operations Experts.