MariaDB Galera Cluster

MariaDB Galera Cluster

Reviewed & updated: September 2026

MariaDB Galera Cluster replicates synchronously across every node using the Write-Set Replication (wsrep) API — a certification-based approach that gets the consistency of synchronous replication without the write-latency penalty a naive two-phase commit would carry. Every node in the cluster accepts both reads and writes, so there is no single primary to fail over from in the traditional sense: when a node goes down, the remaining nodes continue serving traffic (provided the cluster still holds quorum), and the failed node rejoins and resyncs automatically once it is back. That multi-master design is also where most self-managed Galera deployments get into trouble — write conflicts, quorum loss during network partitions, and SST (State Snapshot Transfer) resyncs that saturate the network at the worst possible time are all real failure modes, not theoretical ones. ROSTAN designs the cluster topology (node count, arbitrator placement, cross-datacenter segments where needed), sets conflict-aware application patterns where certification conflicts are likely, and — critically — tests failover by actually killing nodes in a staging cluster before your production traffic depends on it. For teams migrating from a standalone MySQL or MariaDB instance into a Galera cluster, we handle the schema compatibility check (not every storage engine and every DDL pattern is Galera-safe), the initial SST, and a validated cutover plan, followed by 24x7 managed operations — monitoring cluster state (donor/joiner/synced), alerting on quorum risk, and planned maintenance that never takes the whole cluster down at once.