The question lands in my inbox more than any other MariaDB question: should we run Galera, or plain replication? I have run both in production, watched both fail at 3am, and cleaned up after both. The honest answer is that they are not competing versions of the same feature. They are different trades across latency, consistency, failover behavior, and operational burden, and the right choice depends on which failure mode your business can actually afford.
This post walks those trades the way I walk them with teams: what each model genuinely promises, the commit-latency math, what split-brain looks like on each side, how failovers actually go, and a decision framework that has held up across a lot of different workloads.
What asynchronous replication actually promises
With classic MariaDB replication, the primary commits alone. Transactions are written to the binary log, the client gets its OK, and replicas fetch and apply events whenever they get to them. Replication lag is not an error condition; it is the normal state, usually sub-second and occasionally minutes during DDL, backups, or batch storms. MariaDB's GTID implementation — positions in the domain-server-sequence form, like 0-1-548921 — makes promotion and re-pointing far saner than the old file-and-offset dance, and multi-source replication with SHOW ALL SLAVES STATUS exists for topologies beyond one primary and its replicas.
Semi-synchronous replication tightens the promise. It has been built into the server for years — no plugins to install — so you enable rpl_semi_sync_master_enabled on the primary and rpl_semi_sync_slave_enabled on the replicas, and a commit waits until at least one replica acknowledges receiving the event, up to rpl_semi_sync_master_timeout, after which the server falls back to asynchronous behavior rather than hanging. This narrows the data-loss window at failover from "whatever had not replicated" to "close to nothing," at the cost of one network round trip per commit. It is a genuinely good middle setting, and underrated.
What Galera actually promises
Galera replaces the binlog relay with certification-based, virtually synchronous replication. Your transaction executes locally; at COMMIT its writeset is broadcast and certified cluster-wide; once certified, the transaction is guaranteed to exist on every node that keeps quorum. There is no replica lag in the asynchronous sense. Instead of letting a node fall arbitrarily behind, Galera applies backpressure — flow control — that throttles the whole cluster so no member drifts too far. And every node is writable, which is the multi-primary property people buy it for.
The price list is real. Two transactions writing the same row on different nodes collide at commit and one dies with a certification conflict — I wrote a whole field note on that failure mode. A slow node stalls everyone through flow control. Huge transactions hit writeset size limits, and schema changes default to total order isolation, where DDL locks the entire cluster unless you opt into rolling upgrades. None of these are bugs; they are the shape of the guarantee.
Commit-latency math on a napkin
Asynchronous adds nothing to commit latency — the commit path is exactly a standalone server's. Semi-sync adds one round trip to the acknowledging replica. Galera adds a certification round trip, but group commit amortizes it across concurrent committers, so a busy single-writer workload pays modestly. The cliff edge is contention: many writers hammering the same rows across nodes will push throughput below what one asynchronous primary delivers, because certification conflicts turn concurrency into abort-and-retry waste.
Distance changes the answer. Asynchronous replication across regions is routine; lag grows and nobody panics. Galera across regions means every commit pays the wide-area round trip, and flow control events ride on top of link jitter. Assigning nodes to segments with gmcast.segment inside wsrep_provider_options reduces cross-WAN chatter, but it does not change the physics. Keep Galera inside one datacenter and bridge regions with asynchronous replication.
Consistency and split-brain
This is the axis that decides most real decisions. An asynchronous failover can lose the transactions that had not yet replicated, and worse, the old primary can come back with errant transactions that never reached the new primary — reconciling those is measured in engineer-days, and I have spent them. Semi-sync shrinks the window but does not eliminate the reconciliation problem.
Galera's answer is structural. Nodes vote; a partition with quorum continues as the Primary Component, and a partition without quorum flips wsrep_cluster_status to non-Primary and refuses writes. As long as you let quorum do its job — no bootstrapping a second component by hand, no forcing primacy on both sides of a partition — there is no second divergent database to reconcile. Run three nodes, or two nodes plus the garbd arbitrator, and respect quorum math during maintenance. Never having to reconcile split-brain is, frankly, what Galera's complexity budget buys you — if that property is not worth real money to you, the simpler model probably wins.
Failover operations compared
Asynchronous replication has no brain of its own. Something external — MaxScale with auto_failover, orchestrator-style tooling, or a runbook and a pager — must detect the failure, pick the most current replica by GTID, promote it, let the others catch up, and repoint traffic. Rehearsed monthly, this takes minutes. Never rehearsed, it takes as long as it takes, and it will happen during your worst week.
Galera makes failover almost boring: every member is a valid writer, so a proxy health check moves traffic in seconds. The operational weight moves to rejoins — a node that was away briefly catches up incrementally from the gcache (IST), while a node that was away too long needs a full state snapshot transfer (SST) via mariabackup or rsync, with real load on the donor. Know your gcache window and your SST duration before you need them. A quick health check on each model looks like this:
-- asynchronous side: is the replica caught up?
SHOW ALL SLAVES STATUSG
SELECT @@global.gtid_binlog_pos AS binlog_pos,
@@global.gtid_slave_pos AS applied_pos;
-- galera side: is this node healthy right now?
SELECT variable_name, variable_value
FROM information_schema.global_status
WHERE variable_name IN (
'wsrep_cluster_status',
'wsrep_local_state_comment',
'wsrep_cluster_size',
'wsrep_flow_control_paused'
);Choosing, honestly
- Choose asynchronous or semi-sync when you need read scaling and reporting offload, cross-region disaster recovery, version-flexible upgrade paths, or your workload has heavy batch writers that would fight certification all day.
- Choose Galera when you operate in one datacenter, losing committed transactions at failover is unacceptable, you can give writes shard affinity, and the team will genuinely learn wsrep behavior instead of treating it as magic.
- The hybrid most serious shops land on: a Galera cluster inside the primary datacenter for failover symmetry, plus an asynchronous replica to the DR region. The models compose well because they solve different problems.
Watching either model with MonPG (coming soon)
Whichever model this post pushed you toward, the worst outcome is choosing a tradeoff and then losing visibility into it. MonPG's MariaDB work — coming soon, not shipped — is being designed around exactly that: replication lag and GTID drift trended on the asynchronous side, flow-control pauses and certification failures on the Galera side, so the trade you made stays visible instead of theoretical. Today the platform monitors PostgreSQL, full stop; the MariaDB monitoring (coming soon) page shows where the MariaDB effort stands. If you run PostgreSQL alongside MariaDB — common in shops mid-migration — that half of your stack is covered today; the PostgreSQL overview is the place to start.