MVCC (Multi-Version Concurrency Control) with MariaDB Xpand

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

xid

The transaction start identifier generated when the transaction begins

iid

The invocation identifier generated when a statement begins execution within the transaction

cid

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:

Xpand Visibility Rules

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), and cid (commit ID) to determine transaction visibility

  • Xpand 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

xid of executing transaction must be greater than a row version's cid

  • Provides a consistent read during execution of a single transaction

  • Each statement within a transaction sees rows committed before the transaction started and any uncommitted rows changed by the transaction itself

Read Committed

statement

iid of executing statement must be greater than a row version's cid

  • Provides a consistent read during execution of a single statement

  • Each statement within a transaction sees rows committed before the statement started executing

Serializable

transaction

xid of executing transaction must be greater than a row version's cid

  • Only supported for internal use

  • Used internally to perform data moves within the cluster

  • Provides a guarantee that transactions are serializable

  • Raises an error when the MVCC scheduler cannot guarantee serializability

The following diagram shows how transaction visibility works at different isolation levels.

Xpand 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 version

  • Each 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:

Xpand Version History

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 lowest xid value of any currently running transactions