MariaDB Galera Cluster: 3-Node High-Availability Setup

What is Galera Cluster

MariaDB Galera Cluster is synchronous multi-master replication for MariaDB. All three nodes accept write queries at the same time. If one node goes down, the cluster keeps working. Ideal for high-availability applications.

Architecture: 3 Nodes (minimum)

Three servers (node1: 10.0.0.1, node2: 10.0.0.2, node3: 10.0.0.3) running MariaDB. Galera requires an odd number of nodes to prevent split-brain.

Installing MariaDB on All Nodes

# On every server:
sudo apt update && sudo apt install mariadb-server
sudo systemctl stop mariadb

Galera Configuration (on every node)

sudo nano /etc/mysql/mariadb.conf.d/60-galera.cnf

[mysqld]
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0

# Galera Provider
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so

# Galera Cluster
wsrep_cluster_name="my_cluster"
wsrep_cluster_address="gcomm://10.0.0.1,10.0.0.2,10.0.0.3"

# Node identification (different on each node!)
wsrep_node_address="10.0.0.1"    # NODE 1
wsrep_node_name="node1"           # NODE 1

# SST Method
wsrep_sst_method=rsync

First Cluster Start (on node1 only)

# ONLY on the first node:
sudo galera_new_cluster
# or
sudo mysqld --wsrep-new-cluster --user=mysql &

Starting the Remaining Nodes

# On node2 and node3:
sudo systemctl start mariadb

Checking Cluster Status

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_%';" | grep -E "wsrep_cluster_size|wsrep_cluster_status|wsrep_connected|wsrep_ready"

-- wsrep_cluster_size: 3      (all 3 nodes in the cluster)
-- wsrep_cluster_status: Primary
-- wsrep_connected: ON
-- wsrep_ready: ON

Common Galera Cluster Errors

Split-brain and Why You Need an Odd Number of Nodes

Galera decides which part of the cluster is the "Primary Component" by quorum — a simple majority vote of nodes. That is exactly why an odd number of nodes matters:

• 3 nodes: if the network splits between node 1 and node 2, the majority (2 of 3) keeps running, and the minority switches to non-Primary and rejects queries.
• 4 nodes: if the split is exactly even (2 vs 2), neither half has quorum — the whole cluster stops, which is worse than with 3 nodes.
• 2 nodes: any network break between them stops the cluster — Galera on two nodes only protects against one of them failing completely, not against a network partition.

When Galera Cluster Is Not a Good Fit

Synchronous replication means a commit on one node waits for certification acknowledgment from the others — this adds latency to every transaction, especially noticeable between nodes in different data centers. Galera is a poor fit for applications with frequent long transactions and large BLOB/LOB fields: SST and IST (Incremental State Transfer) move data as a whole, and one large transaction can block certification for the entire cluster for a long time. For a typical web application with short transactions and three nodes in one data center, Galera behaves predictably; for writes distributed across regions, asynchronous replication is a better fit.

Diagnosing Cluster Performance

-- Check flow control status (means the node cannot keep up applying transactions)
SHOW STATUS LIKE 'wsrep_flow_control_paused';
SHOW STATUS LIKE 'wsrep_local_recv_queue_avg';

-- Number of certification conflicts (cluster-level deadlock)
SHOW STATUS LIKE 'wsrep_local_cert_failures';

-- InnoDB state on the node under load
SHOW ENGINE INNODB STATUS\G

A wsrep_flow_control_paused value close to 1 means the node spends almost all its time waiting for the others to catch up on writes — usually a sign of a slow disk or network on one of the nodes. Ready-made my.cnf settings for different RAM sizes are in the article on my.cnf optimization, and load balancing across nodes is covered in the article on ProxySQL.

Frequently asked questions

Can a new node be added to an already running cluster without stopping the others?

Adding a new node doesn't require stopping the rest of a running cluster — install the same package on the new server, point its configuration to the existing nodes' addresses, and start the service normally, without the flag that bootstraps a new cluster. The node receives a full data copy through SST and joins the quorum as a write participant.

What should be done if a node drops out of the cluster and needs to rejoin?

A node that dropped out of the cluster is easiest to bring back with a restart — on startup it contacts the remaining nodes and either catches up through an incremental transfer or, if too far behind, downloads the full dataset. The new-cluster bootstrap flag must never run on it — that wipes its data and starts a separate cluster.

Is a dedicated load balancer required in front of the cluster, or is connecting directly to one node enough?

Connecting directly to a single node is possible, but an application loses its database connection the moment that node fails, even if the rest of the cluster is healthy. A load balancer in front of the cluster spreads requests across available nodes and drops one that stops responding, so it's worth setting up for production instead of one fixed address.

How does Galera Cluster differ from regular MySQL master-slave replication?

Regular MySQL replication is asynchronous and built around a single master: writes go only there, while slave nodes catch up with a small lag and serve reads. Galera is synchronous and multi-master — any node accepts writes, and a commit is confirmed after certification across every cluster member, removing slave lag at the cost of extra latency per transaction.