MySQL & MariaDB High Availability in 2026

Kyle Kingsbury's independent Jepsen report (March 16, 2026) on MariaDB Galera Cluster 12.1.2 documented four issues, all unresolved at publication: loss of committed transactions when nodes crash in quick succession (MDEV-38974 — under MariaDB's then-recommended innodb_flush_log_at_trx_commit=0 setting), occasional loss of committed transactions under process crashes plus network partitions even with full durability settings (MDEV-38976), Lost Update (MDEV-38977), and stale reads (MDEV-38999) — the latter two occurring in healthy clusters with no faults injected. Jepsen concluded the observed behavior did not meet Galera's documented isolation claims. The root cause traces to Galera's optimistic certification model, where commit acknowledgement reflects certification agreement rather than completed, durable cluster-wide apply. Continuent's analysis of the findings and trade-off comparison cover the operational implications. Fair caveat, stated in both: Jepsen can demonstrate the presence of anomalies, not their absence in untested systems.

Yes. Following its acquisition of Codership, MariaDB announced that maintenance and binary releases for all current MySQL Galera Cluster versions end on September 30, 2026, after which new clustering features land only in MariaDB Galera Cluster. MariaDB offers an in-place migration from MySQL Galera to MariaDB Galera Cluster; Percona XtraDB Cluster remains the main Galera-based alternative for those staying on the MySQL/Percona side. MySQL Galera users should treat this as a forced architecture decision — and a natural moment to re-evaluate clustering models altogether.

The 2026 Jepsen findings complicate the traditional assumption. Galera's certification is synchronous, but acknowledgement occurs before cluster-wide apply completes — and Jepsen documented committed-transaction loss under overlapping failures plus Lost Update and stale reads in healthy clusters. Meanwhile the same synchrony makes commits sensitive to the farthest node and throughput sensitive to the slowest one. Asynchronous geo-clustering (as in Tungsten composite clusters) accepts a defined, monitored replication lag in exchange for site independence and a single ordered transaction history where commit, reads, and failover agree. The right question isn't "sync or async" but "what does a commit acknowledgement actually guarantee, and what RPO/RTO does each topology deliver under real failure conditions."

Router's SQL-classified splitting is a real capability and a fair baseline. The differences appear during failure and maintenance: how sessions, transactions, and prepared statements are handled while a primary moves, how routing follows multi-site topology, and how traffic is drained for zero-downtime operations. Evaluate proxies on failover behavior under load, not on feature checklists.

At least three different things. Galera and Group Replication multi-primary mean synchronous write-anywhere within one cluster — workload-constrained, latency-bound, and (per Jepsen) exposed to Lost Update in Galera's case. Sharded systems (Vitess) mean each shard has one writer, distributed by key. Tungsten composite active/active means each site runs a full cluster accepting writes, replicated asynchronously between sites with an explicit write-ownership and conflict-avoidance model. Match the model to your application's semantics before comparing anything else.

For AWS-only estates it covers managed cross-region DR well. It does not address cross-cloud or on-premises topologies, uses an Aurora-specific engine rather than community MySQL, and puts failover and maintenance policy on the provider's terms. Whether that matters depends entirely on your portability and control requirements.

It varies widely — and the gap is widening. InnoDB Cluster is MySQL-only. MaxScale and Enterprise Cluster are MariaDB-centric, and Galera's MySQL build is discontinued after September 2026. ProxySQL works across the family. Tungsten Cluster supports MySQL, MariaDB, and Percona Server under one operating model — one of its core differentiators for mixed estates.