MariaDB High Availability
Galera Cluster vs asynchronous and semi-synchronous replication: which high availability for MariaDB?
All three answer different questions: how much data you can lose when the primary fails, how much write latency you accept, and which constraints your application can live with. Here's how to choose, without dogma.
The real question: what happens at commit time?
It all comes down to one moment: when the application gets "OK" after a COMMIT, where does the transaction exist? On the primary only, on at least one other server, or across the whole cluster? The answer sets how much data you may lose on failure, and the latency price paid on every write.
None of the three models is "better" in absolute terms. Well-monitored asynchronous replication with automatic failover suits the vast majority of applications. Galera is justified when losing a committed transaction is unacceptable and the application respects its constraints.
Asynchronous replication: simple, fast, with a loss window
The primary writes the transaction to its binlog and returns to the application. Replicas fetch events afterwards, at their own pace. No wait for a replica at commit time, no distance constraint: a replica can sit in another country for disaster recovery.
The trade-off: if the primary fails, transactions committed but not yet shipped are lost or stuck on the failed server. Replica lag also needs watching: under heavy write load or during a large ALTER TABLE, it can reach several minutes. MariaDB parallel replication can cut it sharply, without guaranteeing zero lag.
Failover isn't automatic: you need a tool that detects the failure, picks the most up-to-date replica, promotes it and repoints the others. That's the job of Signal18 Replication Manager, with GTID making replica repositioning simpler.
Semi-synchronous replication: shrinking the loss window
With semi-sync, the primary waits for at least one replica to acknowledge the transaction before confirming the commit. Since MariaDB 10.3 it's built into the server, no plugin to install: enable rpl_semi_sync_master_enabled on the primary and rpl_semi_sync_slave_enabled on replicas.
Two settings make all the difference. The wait point: with AFTER_SYNC, the primary waits for the acknowledgement before making the transaction visible, so no client reads data that would vanish after a failover. MariaDB's default is AFTER_COMMIT: check yours. The timeout: if no replica answers in time (rpl_semi_sync_master_timeout, 10 seconds by default), the primary falls back to asynchronous without failing commits. Only the error log records it, and semi-sync resumes on its own once a replica catches up. Without monitoring Rpl_semi_sync_master_status, you can run async without knowing.
Two limits to keep in mind. "Received" doesn't mean "applied": a replica can hold the transaction in its relay log without having executed it yet, so reads there still lag. And every commit waits for the acknowledgement of the first replica to answer: network plus its relay log write. Replication Manager can make automatic failover conditional on replication being in sync (failover-at-sync), avoiding the promotion of a replica known to be incomplete.
Galera Cluster: certification-based synchronous replication
With Galera, built into MariaDB, every transaction is broadcast to all nodes at commit time, in the same order everywhere, then certified: each node checks it doesn't conflict with a concurrent transaction. A committed transaction is known to every node of the primary component. There's no replica to promote: if a node fails, the others carry on. A node can still lag slightly in applying changes, bounded by flow control.
Quorum protects against split-brain: a node cut off from the rest of the cluster switches to non-primary state and refuses queries. A two-node cluster works, but can't survive the unplanned failure of one node. Hence the three voting members rule (three data nodes, or two nodes plus a garbd arbitrator), ideally across three separate sites.
The constraints are real. Every commit pays at least one network round trip to the other nodes: close sites are preferred, typically within the same metro area. A WAN deployment is possible, but long-distance latency is then added to every write. The slowest node throttles the whole cluster (flow control). In production you use InnoDB and an explicit primary key on every table (MyISAM and Aria are only experimentally supported). Transaction size is limited; since Galera 4 (MariaDB 10.4), streaming replication fragments very large transactions, at a cost. An ALTER TABLE blocks writes across the whole cluster by default while it runs (TOI mode).
Writing to several nodes at once is possible, but when two transactions touch the same rows on two different nodes, one of them is aborted and the application gets a deadlock error (only some autocommit statements are retried automatically, via wsrep_retry_autocommit). In practice, writes are routed to a single node through a proxy (ProxySQL, MaxScale or HAProxy), and the others are kept for reads and failover.
Side-by-side comparison
The three models, criterion by criterion. None wins on every line.
| Criterion | Asynchronous | Semi-synchronous | Galera Cluster |
|---|---|---|---|
| When the commit returns | Once written locally | Once at least one replica has received the event | Once the write set is certified across the cluster |
| Data loss on primary failure | Possible (events not yet shipped) | Limited, if wait point is AFTER_SYNC and no timeout occurred | None for committed transactions, as long as quorum survives (if the whole cluster goes down at once, it depends on flush settings) |
| Extra write latency | No wait for a replica in the commit path | Waits for the first replica acknowledgement (network + relay log write) | At least one round trip to the other nodes, on every commit |
| Reads on secondaries | Possible, with lag | Possible, with lag (received ≠ applied) | Possible; causal reads with wsrep_sync_wait |
| Writes on several nodes | Single writer in the standard topology (multi-primary rings exist, without conflict detection) | Single writer in the standard topology | Possible, but conflicts on hot rows: single writer recommended |
| Minimum nodes | 2 | 2 | 3 voting members to survive a failure (3 data nodes, or 2 + garbd) |
| Failover | External tool (e.g. Replication Manager) | External tool (e.g. Replication Manager) | No promotion: the proxy stops sending traffic to the lost node |
| Distance between sites | Any, even continents apart | Latency-sensitive, same region preferred | Low latency preferred (same metro area); WAN possible, but every commit pays the distance |
| Schema constraints | Few | Few | InnoDB (MyISAM/Aria experimental), explicit primary key on every table strongly recommended |
| Large transactions / DDL | Replica lag | Replica lag | Write-set size limit (streaming replication for large ones); DDL blocks writes cluster-wide by default (TOI) |
Which model for which situation?
Typical web application, a few seconds of loss acceptable on a rare failure
Asynchronous + automatic failover (Replication Manager). The simplest to operate.
Reduce data loss without touching the application
Semi-sync with AFTER_SYNC, with monitoring of the fallback to async.
No committed transaction may be lost, sites close together
3-node Galera across 3 sites, single writer through a proxy.
Standby replica in another region or country
Asynchronous. Over that distance, the latency added to every synchronous commit is rarely acceptable.
Tables without primary keys, MyISAM, very large batch transactions
Classic replication, or fix the schema before considering Galera.
Need to scale reads
All three work; account for lag on asynchronous replicas.
What about MySQL?
Asynchronous and semi-synchronous replication also exist on MySQL, with variable names that differ across versions. Galera is available for MySQL through Percona XtraDB Cluster. Oracle's native solution, Group Replication / InnoDB Cluster, relies on a different protocol. We don't support it: on MySQL, our scope covers standalone servers and classic replication.
What we run at RDEM Systems
Our two MariaDB as a Service topologies map onto this comparison: replication across 2 datacenters driven by Replication Manager, and Galera Cluster across 3 datacenters in the Paris region, close enough to keep certification latency low.
Our own PKI infrastructure runs on Galera: architecture, quorum and monitoring are detailed in the 3-node Galera cluster case study. If you're torn between models, the MariaDB audit first checks whether your schema and transactions are Galera-compatible.
Frequently asked questions
Is Galera really synchronous?
Broadcast and certification are synchronous: a committed transaction is known to every node of the primary component. Applying it on each node is slightly deferred, hence the term "virtually synchronous". To make sure a read sees the latest writes, use wsrep_sync_wait.
Does semi-synchronous replication guarantee zero data loss?
No. It sharply narrows the loss window with the AFTER_SYNC wait point, but falls back to asynchronous if no replica answers before the timeout. The fallback is logged, but until it is monitored, the guarantee is theoretical.
Can you run a Galera cluster with two nodes?
It works, but if one fails unexpectedly, the other loses quorum and refuses queries. To tolerate a failure you need a third member, which can be a data-less garbd arbitrator.
Should you write to every Galera node?
You can, but concurrent writes to the same rows abort one of the transactions, which the application has to retry. Common practice is a single writer node, the others serving reads and failover.
Does your high availability actually hold when something fails?
The MariaDB audit reviews topology, replication, failover and your schema's compatibility with Galera.
Start your managed MariaDB project
Let's discuss your database needs. Our DBA team advises you on the optimal architecture for your use case.
RDEM Systems SAS — SIREN 820 338 671 — 5 B rue des Noyers, 95300 Pontoise