SUMMARY:
Learn why MariaDB Galera Cluster uses virtually synchronous replication and how write-set certification delivers consistency and performance.
Table of contents
Introduction
MariaDB Galera Cluster is often described as a synchronous replication solution, but technically it uses a model known as virtually synchronous replication. Understanding this distinction helps explain how Galera delivers strong consistency while avoiding some of the performance limitations of traditional synchronous systems.
In a typical asynchronous replication environment, a transaction is committed on the primary server, and the client immediately receives a success response. The changes are then sent to replica servers afterward. While this approach provides good performance, it can introduce replication lag and the risk of data loss during failover.
A fully synchronous system works differently. A transaction is not considered committed until every participating node has received and applied the transaction. This guarantees consistency but increases latency because each commit must wait for all nodes to finish processing the transaction.
Galera takes a middle-ground approach.
When a transaction is committed on a Galera node, the changes are packaged into a write set and distributed to all cluster members. Each node then verifies that the transaction does not conflict with other transactions already accepted by the cluster. Once all nodes agree that the transaction is valid, the commit is approved the client receives a success response.
The process can be simplified as follows:
Client
|
v
1. Execute Transaction (Optimistic Execution)
|
v
2. Generate Write Set (Primary keys & row changes)
|
v
3. Broadcast to Cluster (via GComm framework)
|
v
4. Deterministic Certification Check (On ALL nodes simultaneously)
|
v
5. Originating Node Commits Locally (Applies changes to its storage engine)
|
v
6. Client Receives COMMIT Success Message
|
v
7. Replica Nodes Queue & Apply (Asynchronously applied in background via slave threads)Why “Virtually” Synchronous?
The key difference is that Galera does not wait for every node to fully apply the transaction before acknowledging the commit.
Before a COMMIT succeeds, all nodes must:
- Receive the write set
- Agree on the global transaction order
- Successfully certify the transaction
- Confirm that no conflicts exist
Once these steps are completed, the client receives a successful COMMIT response.
The actual application of the transaction may still be occurring on some nodes in the background. Since every node has already agreed on the transaction order and outcome, consistency is preserved throughout the cluster.
This is why Galera is referred to as virtually synchronous rather than fully synchronous.
Certification-Based Replication
One of Galera’s most innovative features is its certification-based replication mechanism.
Instead of using distributed locks across nodes, transactions execute locally and are validated during the commit phase. If two nodes attempt to update the same row simultaneously, Galera detects the conflict during certification and allows only one transaction to succeed. The conflicting transaction is rolled back and must be retried by the application.
This approach allows Galera to support:
- Multi-primary writes
- Strong consistency
- Automatic conflict detection
- High availability
Without the overhead of cluster-wide locking.
Benefits of Virtual Synchrony
The virtually synchronous model provides several operational advantages:
- Eliminates traditional replication lag
- Keeps all cluster nodes logically consistent
- Simplifies failover operations
- Supports active-active database architectures
- Removes the need to identify the most up-to-date replica during failover
As a result, applications can continue operating even if a node becomes unavailable.
Trade-Offs to Consider
Like any distributed system, Galera’s design comes with trade-offs.
- Network latency directly affects commit performance.
- Write-intensive workloads can experience certification conflicts.
- Flow control may slow down the cluster if one node falls behind.
- Multi-primary environments may require applications to handle transaction retries.
These considerations are important when designing geographically distributed or high-write environments.
Conclusion
Galera is called virtually synchronous because all nodes must receive and certify a transaction before the commit is acknowledged, but they do not need to fully apply the transaction before the client receives a success response.
This approach combines the consistent benefits of synchronous replication with better performance and scalability than traditional synchronous systems. By leveraging write-set replication and certification-based conflict detection, Galera provides a practical balance between consistency, availability, and performance, making it one of the most popular high-availability solutions for MariaDB deployments.