Multi-Master MariaDB Clustering
MariaDB Galera Cluster Services
In short: MariaDB Galera Cluster is a synchronous, multi-master clustering solution built on the Galera library and the wsrep API. Every node accepts reads and writes, and certification-based replication applies each committed transaction on all nodes virtually simultaneously, so a node failure does not lose committed transactions (RPO=0 on node loss) and there is no single point of failure.
Deploy production-grade MariaDB Galera Cluster with synchronous multi-master replication, automatic node provisioning, and certification-based conflict resolution for mission-critical workloads.
JusDB delivers production-grade MariaDB Galera 4 cluster engineering with synchronous replication and automated, drill-tested failover. JusDB DBREs tune write-set certification, calibrate flow control (gcs.fc_limit), deploy garbd arbiters for split-brain prevention, optimize non-blocking mariabackup state transfers, and configure MaxScale causal routing, with incident response at agreed initial-response targets.
Comprehensive MariaDB Galera Cluster Services
From initial cluster deployment through performance tuning and disaster recovery, we deliver end-to-end Galera Cluster solutions for enterprise environments.
Galera Cluster Deployment
Full cluster setup and configuration with wsrep provider, node bootstrapping, and production hardening
- Cluster initialization and bootstrap
- wsrep provider and Galera library configuration
- SSL/TLS encryption for IST and SST streams
- Network and firewall configuration (ports 4567, 4568, 4444)
Node Provisioning
Automated state transfer configuration for seamless node joining and cluster scaling
- SST method selection (mariabackup, rsync, mysqldump)
- IST configuration with optimized gcache sizing
- Donor node selection and load-aware policies
- Rolling node addition without cluster downtime
Multi-Master Configuration
True multi-master write capabilities with certification-based conflict handling
- Certification-based replication tuning
- Write conflict detection and resolution strategies
- Application-level write partitioning guidance
- Deadlock retry logic and best practices
Performance Optimization
Advanced tuning for flow control, parallel apply threads, and gcache to maximize throughput
- Flow control tuning (gcs.fc_limit, gcs.fc_factor)
- Parallel apply threads (wsrep_slave_threads)
- gcache sizing for IST window optimization
- WAN replication tuning (evs.send_window, segment config)
Monitoring & Management
Comprehensive wsrep status monitoring, alerting, and proactive cluster health management
- wsrep status variables monitoring and dashboards
- Flow control and replication lag alerting
- Cluster state change notifications
- Performance Monitoring with PMM or custom tooling
Disaster Recovery
Backup strategies, cluster recovery procedures, and bootstrap protocols for any failure scenario
- Automated backup with mariabackup integration
- Cluster recovery from total outage (safe-to-bootstrap)
- Split-brain recovery and quorum restoration
- Point-in-time recovery with binary log coordination
Why Choose MariaDB Galera Cluster?
Galera Cluster delivers true multi-master synchronous replication with no single point of failure, making it the gold standard for MySQL-compatible high availability.
Synchronous Replication
Every transaction is replicated and certified on all nodes before the commit is acknowledged (virtually synchronous, certification-based replication), so a node failure does not lose committed transactions and nodes do not diverge.
Multi-Master Writes
Every node in the cluster is a full read/write master. Applications can direct writes to any node, enabling geographic write distribution, load balancing, and eliminating single-writer bottlenecks.
Automatic Node Join (SST/IST)
New or recovering nodes automatically receive the cluster state through SST (full snapshot) or IST (incremental delta). No manual intervention is required — the cluster self-heals and re-provisions nodes transparently.
No Single Point of Failure
The shared-nothing architecture means every node holds a complete copy of the data. If any node fails, the remaining nodes continue serving reads and writes with no downtime and no data loss, as long as quorum is maintained.
Galera at a Glance
Supported Platforms
Galera Cluster Architecture
Understanding the four core components that make Galera Cluster the most reliable MySQL-compatible multi-master solution available.
wsrep API
Write-Set Replication Interface
The wsrep API is the interface layer between MariaDB and the Galera replication library. It captures transaction write-sets at commit time and passes them to the Galera plugin for replication. This clean abstraction allows Galera to work with any wsrep-compatible database engine without modifying the storage layer.
Group Communication
GCS / GComm Protocol
The Group Communication System (GCS) handles cluster membership, message ordering, and delivery guarantees. Built on the GComm protocol, it provides virtual synchrony — ensuring all nodes see the same sequence of messages in the same order, which is the foundation for consistent certification across the cluster.
Certification
Deterministic Conflict Detection
Each node independently certifies incoming write-sets against its local pending transactions. Certification compares primary key ranges to detect conflicts deterministically — every node reaches the same certification decision without coordination. Conflicting transactions are rolled back on the originating node with a deadlock error.
State Transfers
SST and IST Provisioning
State transfers provision new or recovering nodes. SST (State Snapshot Transfer) sends a full data snapshot via mariabackup, rsync, or mysqldump. IST (Incremental State Transfer) replays only the missing write-sets from the donor's gcache. IST is non-blocking and fast, making proper gcache sizing critical for operational resilience.
Galera Cluster vs. InnoDB Cluster
Both solutions deliver synchronous replication and high availability, but their architectures and operational characteristics serve different use cases.
MariaDB Galera Cluster
True multi-master with certification-based synchronous replication
Galera Cluster is purpose-built for multi-master workloads where every node must accept writes. Its certification-based approach and mature state transfer mechanisms make it ideal for organizations that need proven, battle-tested clustering with MariaDB.
MySQL InnoDB Cluster
Integrated clustering with Group Replication, MySQL Shell, and MySQL Router
InnoDB Cluster is Oracle's native MySQL clustering solution that bundles Group Replication with MySQL Shell (AdminAPI) and MySQL Router. It provides a tightly integrated stack with single-primary as the default mode and optional multi-primary.
Our Galera Cluster Implementation Process
A systematic approach to deploying MariaDB Galera Cluster with comprehensive testing, validation, and documentation at every stage.
Architecture Planning
Analyze your workload patterns, latency requirements, and availability targets. Design the cluster topology — number of nodes, network segments, SST methods, and proxy layer selection (ProxySQL, HAProxy, or MaxScale).
Cluster Bootstrap
Initialize the first node with galera_new_cluster, configure wsrep provider options, set up SSL/TLS for replication streams (covered in depth by our MariaDB security audit), and join additional nodes. Validate certification and state transfer functionality before proceeding.
Integration & Testing
Configure the proxy layer for read/write splitting and health checks. Perform failover testing, SST/IST validation, network partition simulation, and application compatibility verification under realistic load.
Production Deployment
Deploy to production with comprehensive monitoring dashboards, alerting on wsrep status variables and flow control, automated backup schedules, and runbook documentation for operational procedures.
How JusDB MariaDB Galera Engineering compares to alternative models.
Standard cloud hosting and generalist system administrators lack deep Galera wsrep internals, certification conflict tuning, non-blocking SST optimization, and DBRE incident response. Here is how our MariaDB Galera specialists compare:
| Evaluation Vector | JusDB DBRE | In-House DBA | Legacy Agency | Developer Generalist |
|---|---|---|---|---|
| Virtually Synchronous Multi-Primary Replication & Certification | Configures certification-based replication with wsrep_certify_nonPK=ON, tuned wsrep_slave_threads aligned to CPU cores, and deterministic primary key range conflict detection for true RPO=0 synchronous clustering. | Runs default single wsrep_slave_thread and ignores write conflicts, causing write-set certification backlogs and app-level transaction deadlocks. | Treats Galera like standard async MySQL master-slave; uses raw multi-master writes without conflict-aware transaction retries, causing data rollbacks. | Deploys multi-master without understanding optimistic locking or write-set certification, generating unhandled wsrep certification aborts. |
| Flow Control (gcs.fc_limit) & Slave Queue Memory Sizing | Calibrates gcs.fc_limit, gcs.fc_factor, and wsrep_local_recv_queue sizing with proactive telemetry to eliminate flow control pauses (wsrep_flow_control_paused=0) under write spikes. | Leaves gcs.fc_limit at default (16), causing a single slow disk or donor node to trigger cluster-wide write freezes during batch imports. | Blindly increases gcs.fc_limit to extreme values, causing runaway slave queue memory consumption and out-of-memory kernel panics. | Does not monitor wsrep_flow_control_paused; misattributes cluster-wide transaction stalls to network outages or web application bugs. |
| State Transfer Optimization (SST via mariabackup vs IST) | Hardens mariabackup non-blocking SST with dedicated replication VLANs and sizes gcache.size so maintenance restarts can rejoin via fast Incremental State Transfers (IST) instead of full SST. | Relies on blocking rsync SST or undersized gcache (128MB), forcing heavy full SST copies that evict donor nodes from serving live production traffic. | Uses deprecated mysqldump SST, taking global table locks on donor nodes and crashing production application response times. | Lets joiner nodes crash due to timeout during large SST transfers without configuring stream compression or parallel donor threads. |
| Split-Brain Protection & Galera Arbitrator (garbd) Quorum | Deploys odd-numbered voting topologies across availability zones using Galera Arbitrator (garbd) with evs.suspect_timeout and evs.inactive_timeout hardened for cloud networks. | Deploys an even 2-node cluster without an arbiter; a transient network partition triggers split-brain and non-primary component isolation on both nodes. | Relies on manual wsrep_cluster_address resets or unsafe pc.ignore_sb=TRUE, risking silent data divergences across divergent partitions. | Ignores quorum requirements entirely; leaves partitioned nodes running in non-primary state unable to accept write operations. |
| MaxScale Read/Write Splitting & Causal Consistency Routing | Integrates MaxScale with Galera-Monitor, causal_reads=true, and master_failure_mode=fail_on_write, preventing stale reads after writes and enabling transparent failover. | Uses basic round-robin HAProxy without wsrep status checks, routing application write traffic to non-primary or desynchronized joiner nodes. | Hardcodes node IPs directly in application connection pools, requiring manual configuration edits and service restarts during node outages. | Connects applications directly to random Galera nodes without proxy layers, causing frequent cross-node write lock deadlocks and timeouts. |
| Disaster Recovery & Automated Primary Component Rebootstrap | Architects automated cluster bootstrap recovery using grastate.dat safe_to_bootstrap discovery, coordinated binary log sequence analysis, and PITR via encrypted mariadb-backup. | Manually edits safe_to_bootstrap: 1 on a random node during power outages without seqno verification, causing silent data loss of recent commits. | Attempts mysqld_safe --wsrep-new-cluster on an outdated node, overwriting the true latest state and corrupting cluster GTID sequence tracking. | Restores stale logical SQL dumps after cluster crashes instead of safely re-bootstrapping existing Galera storage engines. |
Critical Galera Outage Modes We Eliminate
High-concurrency MariaDB Galera clusters face severe production failure modes when flow control freezes writes cluster-wide, State Snapshot Transfers (SST) knock donor nodes offline, or network partitions destroy primary component quorum. Our DBREs resolve these breakdown modes:
Flow Control Pauses Freezing All Cluster Writes
When a lagging or overloaded cluster node cannot apply replicated write-sets fast enough, its local receive queue exceeds gcs.fc_limit. The node transmits flow control pause signals, halting commit operations across all multi-master nodes cluster-wide.
JusDB tunes gcs.fc_limit and gcs.fc_factor thresholds, scales wsrep_slave_threads proportionally to CPU cores, enables streaming replication for large bulk transactions, and isolates lagging donor nodes before backpressure propagates.
SST State Snapshot Transfer Stalling Donor Node
When a desynchronized node rejoins and requires a full State Snapshot Transfer (SST), suboptimal SST methods (such as mysqldump or unoptimized rsync) lock tables or saturate donor I/O, causing the donor node to become unresponsive and drop out of the cluster.
JusDB implements non-blocking mariabackup SST with TLS encryption and dedicated streaming ports, sizes gcache.size to maximize fast Incremental State Transfers (IST), and routes donor selection to dedicated backup nodes.
Network Partition Causing Primary Component Quorum Loss
Transient network splits or inter-AZ connectivity drops partition nodes into isolated sub-clusters. Without odd-numbered voting members, nodes cannot achieve majority quorum (>50%), forcing the entire cluster into non-primary state and rejecting writes.
JusDB deploys odd-numbered topologies using lightweight Galera Arbitrator (garbd) daemons across independent availability zones, and tunes evs.keepalive_period and evs.suspect_timeout to prevent premature split-brain quorum drops.
Our Galera DBREs execute non-blocking CLI telemetry inspections to evaluate cluster quorum, flow control pause duration, and certification queue health without interrupting active client transactions:
Inspects Galera cluster membership status, active node count, node readiness, and monitors flow control pause intervals to diagnose cluster-wide write throttling.
# Inspect Galera cluster size, primary component status, readiness, and flow control pauses mysql -e "SHOW GLOBAL STATUS LIKE 'wsrep_%';" | grep -E "(wsrep_cluster_size|wsrep_cluster_status|wsrep_ready|wsrep_flow_control_paused)"
Audits local receive and send queue depths along with certification conflict failure counters to pinpoint slave thread apply bottlenecks.
# Audit local Galera receive/send queue averages and certification failure counters mysql -e "SHOW GLOBAL STATUS LIKE 'wsrep_%';" | grep -E "(wsrep_local_recv_queue_avg|wsrep_local_send_queue_avg|wsrep_local_cert_failures)"
Frequently Asked Questions About MariaDB Galera Cluster
Common questions about Galera Cluster architecture, deployment, and operations.
Ready to Deploy Multi-Master MariaDB Clustering?
Let our Galera Cluster experts design, deploy, and optimize a production-grade multi-master cluster for your mission-critical workloads, with synchronous replication and no single point of failure.
Related MariaDB Services
Explore more ways our MariaDB experts can help optimize your database infrastructure
Need a different MariaDB service? Browse our complete offerings.