1 Background
MariaDB is a popular open source SQL database which began as a fork of MySQL. MariaDB Galera Cluster is an active-active replication system for MariaDB which allows reads and writes on every node. In 2015 this author analyzed MariaDB with Galera Cluster and found that although Galera claimed to offer Snapshot Isolation, Codership Oy intentionally designed their system without a key Snapshot Isolation property, called first-committer-wins. This allowed MariaDB with Galera Cluster to lose or create money out of thin air in a simulated bank account transfer workload. In 2025 MariaDB acquired Codership Oy, bringing Galera Cluster under the MariaDB umbrella.
Galera Cluster is based on virtual synchrony group communication framework called gcomm . Transactions are initially executed optimistically on any node. When a transaction commits it is synchronously replicated to other nodes, which certify the transaction based on the primary keys it wrote. Conflicts with other transactions are identified based on a sequence number, or seqno.
The MariaDB Galera Replication Guide says that Galera uses unanimous replication:
Unlike traditional asynchronous or semi-synchronous replication, Galera ensures that transactions are committed on all nodes (or fail on all) before the client receives a success confirmation.
This is obviously wrong. If Galera actually required transactions to commit on all nodes, it would not tolerate a single node failure. MariaDB’s documentation often repeats this claim, saying “a transaction is not truly considered committed until it has passed certification on all nodes”, or “when a transaction COMMIT s, all nodes in the cluster have the same value”, or “only after Node A gets an ‘OK’ from all other nodes does it tell the client, ‘Your transaction is committed.’” In reality, Galera Cluster continues to operate when a minority of nodes has failed. This is consistent with MariaDB’s claims about fault tolerance: if a quorum of nodes are online and connected, that component can make progress.
Galera used to require a manual recovery procedure when quorum was lost: an operator would have to log in to every node, identify the node with the highest sequence number, and use it to bootstrap the cluster. However, newer versions of Galera can recover from failures automatically.
1.1 Safety
“Data is consistent across all nodes at all times,” says the Galera Cluster Replication Guide, “preventing data loss upon node failures.” Galera “essentially transforms a set of individual MariaDB servers into a robust, highly available, and consistent distributed database system.”
This system should provide a real-time consistency model like Strong Snapshot Isolation. MariaDB’s Galera Cluster Guide says that Galera Cluster’s synchronous replication means that changes are “instantly replicated to all other nodes, ensuring no replica lag and no lost transactions.” The “no lost transactions” claim is repeated in MariaDB’s Galera Cluster README.
... continue reading