MVCC (Multi-Version Concurrency Control) with MariaDB Xpand
This page is part of MariaDB's Documentation.
The parent of this page is: Concurrency Control for MariaDB Xpand
Topics on this page:
Overview
MariaDB Xpand supports mixed read-write workloads with concurrency requirements:
Xpand implements a distributed Multi-Version Concurrency Control (MVCC) scheme
Xpand generates multiple IDs for concurrency control:
At the beginning of each transaction, Xpand generates an
xid
(transaction ID)At the beginning of each statement within a transaction, Xpand generates an
iid
(invocation ID)When a transaction is committed, Xpand generates a
cid
(commit ID)
Xpand maintains a version history of row changes in the undo log
Xpand uses the version history to build consistent reads and to rollback transactions
Xpand regularly trims the undo log removing old row versions from the undo log when they are no longer needed for old transactions
Compatibility
Information provided here applies to:
MariaDB Xpand 5.3
MariaDB Xpand 6.0
MariaDB Xpand 6.1
Transaction, Invocation, and Commit IDs
MariaDB Xpand generates several identifiers associated with each transaction, invocation, and commit:
Identifier | Description |
---|---|
| The transaction start identifier generated when the transaction begins |
| The invocation identifier generated when a statement begins execution within the transaction |
| The commit identifier generated when the transaction is committed |
Xpand generates the xid
and iid
identifiers using a combination of system wide clock and a unique instance id
to create a globally unique ordered identifier.
The following diagram shows several IDs generated throughout a transaction:
Transaction Visibility Rules
MariaDB Xpand uses transaction visibility rules to determine which row version should be visible for a given transaction:
Xpand has different transaction visibility rules for each transaction isolation level
Xpand uses the
xid
(transaction ID),iid
(invocation ID), andcid
(commit ID) to determine transaction visibilityXpand does not support the Read Uncommitted transaction isolation level, so an uncommitted transaction is never visible to other transactions
Xpand only supports the Serializable transaction isolation level for internal use
The following table describes the transaction visibility rules for each transaction isolation level:
Isolation Level | Snapshot Anchor | Visibility Rule | Description |
---|---|---|---|
Repeatable Read (default) | transaction |
|
|
Read Committed | statement |
|
|
Serializable | transaction |
|
|
The following diagram shows how transaction visibility works at different isolation levels.
Undo Log
MariaDB Xpand uses an undo log for MVCC:
The undo log contains a version history of row changes
The undo log is trimmed regularly to perform garbage collection of the version history
Version History
MariaDB Xpand maintains a version history of row changes in the undo log:
The version history is used to access previous row versions to build a transaction's consistent reads for lockless reads
The version history is used to rollback transactions
When a row changes, the old version of the row is added to the version history in the undo log
Each row version contains the
cid
of the transaction that originally committed the row versionEach row version contains a Log Sequence Number (LSN) that points to the previous version of the row
If a row version's LSN is less than the trim LSN, then the row version is at the end of the history chain
The following diagram shows how Xpand keeps multiple versions of the row in the undo log:
Trim and Garbage Collection
MariaDB Xpand regularly trims the undo log to perform garbage collection:
Xpand removes old row versions from the undo log when they are no longer needed for old transactions
A row version is no longer needed for old transactions when the row version's
cid
value is lower than the lowestxid
value of any currently running transactions