Galera vs Async Replication: Failover Trade-offs

Choosing between a synchronous Galera cluster and a classic asynchronous primary/replica pair is, at its core, a decision about how you want failover to behave — how much data you can lose, how long writes are unavailable, and how likely you are to end up with two divergent copies of the truth. This guide, part of Automated Failover & Quorum Recovery in Galera, compares the two failover models head to head across the dimensions that decide an SLA: recovery point (RPO), recovery time (RTO), split-brain exposure, write latency, and the tooling each demands. It is deliberately about failover semantics, not about read scaling — the read-offload decision has its own home in When to Use Async Replicas with Galera.

Context: Two Fundamentally Different Failure Contracts #

The two architectures make opposite promises at commit time, and everything about their failover behaviour follows from that one difference. In a Galera cluster, a transaction is not acknowledged to the client until its write-set has been ordered and certified on a quorum of nodes — so every committed transaction already exists, certified, on every surviving member. Failover therefore loses no committed data: there is nothing to catch up, because the survivors are already caught up. That guarantee is the synchronous certification contract, and its price is that every commit pays the inter-node round-trip.

Asynchronous replication makes the opposite trade. The primary commits locally and acknowledges the client immediately, then ships the binary log to replicas that apply it after the fact. Commits are fast — no peer round-trip — but a replica always trails the primary by some replication lag, and if the primary dies before a transaction reaches the replica, that transaction is gone. Failover means promoting a replica that may be missing the primary’s last few seconds of writes, and doing so while making sure the old primary can never come back and re-inject them.

This is the whole comparison in miniature: Galera trades write latency for a zero-data-loss, self-arbitrating failover; async trades data-loss risk and manual promotion for fast local commits and geographic freedom. Neither is universally correct.

Solution: Match the Model to the Failure You Must Survive #

Recovery point (RPO): zero versus the lag window #

If your requirement is that a node failure loses no committed transaction, Galera delivers it by construction — the certification quorum means every acknowledged commit is already on the survivors. Async cannot promise this: whatever the primary committed but had not yet shipped when it died is lost, and that window is exactly your replication lag, which balloons under write bursts precisely when a failure is most likely. Semi-synchronous replication narrows the gap by making the primary wait for one replica to acknowledge receipt (not apply), but it still trails Galera’s full-quorum certification and can silently downgrade to async under timeout. For a hard zero-RPO SLA on OLTP data, the synchronous model is the direct answer.

Recovery time (RTO): recompute versus promote #

Galera failover is a quorum recomputation that the surviving majority performs automatically in seconds, with no node “promotion” because every node is already a writable master — as long as a majority survives, writes simply continue on the remaining members, and clients are steered there by a proxy health check. Async failover is a multi-step external procedure: detect the primary is dead (and be sure it is dead, not just partitioned), pick the most up-to-date replica, promote it, and repoint every other replica and the application at the new primary. Each step is a place to be wrong, and the detection-versus-partition ambiguity is where async failover most often causes an outage or a split. The Galera-side automation for the recompute path is built out in the failover and quorum-recovery guide.

Split-brain: arithmetic versus fencing #

Galera prevents split-brain with quorum arithmetic: a minority partition transitions to non-Primary and stops accepting writes on its own, so two writable copies cannot form under default settings — the failure mode only appears if you disable protection with pc.ignore_sb, covered in Recovering from a Non-Primary Component. Async has no built-in equivalent: if you promote a replica while the old primary is merely partitioned, both accept writes and diverge. Avoiding that requires explicit fencing (STONITH, a VIP the old primary loses, or read_only enforcement) driven by external tooling. Split-brain is a design-time property in Galera and an operational discipline in async.

Write latency and geography #

The costs run the other way. Every Galera commit waits for the write-set to be ordered across the group, so inter-node round-trip time is added to write latency — beyond roughly 10 ms RTT the group throttles under flow control, which is why cross-region synchronous clusters are usually the wrong tool. Async commits locally and ships the log afterward, so it tolerates high-latency, cross-region links comfortably; a replica in another continent slows nothing on the primary. When your topology is inherently wide-area, async (or a synchronous core with an async replica for the far region) is the pragmatic failover boundary.

Decision Matrix #

Verification: Prove Your Failover Actually Meets the SLA #

Whichever model you run, do not trust the theory — measure it. For a Galera cluster, confirm that a killed node loses no committed data and the survivors stay writable:

# Before: record the committed seqno on a healthy node
mariadb -N -B -e "SHOW GLOBAL STATUS LIKE 'wsrep_last_committed';"
# Kill one node, then confirm survivors are still Primary and writable
mariadb -N -B -e "SHOW GLOBAL STATUS WHERE Variable_name IN \
  ('wsrep_cluster_status','wsrep_cluster_size','wsrep_local_state_comment');"

For an async pair, measure the RPO you would actually take by reading the replica’s lag and the unshipped tail on the primary:

-- On the replica: how far behind is it right now? (this is your worst-case RPO)
SHOW REPLICA STATUS\G   -- read Seconds_Behind_Source and the applied coordinates

A replica reporting Seconds_Behind_Source above your RPO budget means a primary failure right now would breach the SLA — that is the signal to move latency-sensitive, zero-loss data onto the synchronous model, or to add semi-sync. Wire either probe into the health checks in Automated Node Health Monitoring.

Edge Cases & Gotchas #

• “Synchronous” does not mean “synchronously applied.” Galera blocks the client only until the write-set is ordered and certified, not until every peer has finished applying it — remote apply happens behind the total order under flow control. This is still zero-RPO for failover (a certified transaction survives on every member) but it means a just-committed row may be a few milliseconds from being readable on a peer. Do not conflate Galera’s failover guarantee with read-your-writes across arbitrary nodes.
• Async failover’s real risk is the false positive. The most damaging async incident is not a primary that died — it is a primary that was briefly unreachable, got its replica promoted, and then came back writable. Now two primaries have accepted conflicting writes. Any async failover automation must fence the old primary (force read_only, drop its VIP, or power-fence it) before promoting, or you trade a short outage for permanent divergence.
• A hybrid often beats a pure choice. The common production answer is not either/or: run a synchronous Galera core for zero-RPO local failover and attach an async replica for the far region or for backups. The synchronous group owns the write path and its automatic failover; the async replica absorbs geography and DR without taxing commit latency. The trigger for adding that replica is exactly the subject of When to Use Async Replicas with Galera.

Related #

• Automated Failover & Quorum Recovery in Galera — the synchronous failover mechanics this comparison measures against
• When to Use Async Replicas with Galera — when to attach an async replica to a synchronous core (the read/DR decision, not failover)
• Understanding Galera Synchronous Replication — why a certified commit implies zero-RPO failover
• Recovering from a Non-Primary Component — the quorum guard that makes split-brain a design-time property