MariaDB Galera Cluster: Three-Node Multi-Primary Setup

Galera Cluster turns several MariaDB servers into a synchronous multi-primary cluster: every node accepts reads and writes, and a transaction commits only when all nodes have certified it. If one node fails, the others keep serving with no data loss and no manual failover. Galera is built into MariaDB.

When it fits

You need high availability for a MySQL-compatible database without complex failover tooling.
Workloads that are read-heavy or have moderate writes.

Trade-offs:

Write latency increases (every commit waits for the cluster), so nodes should be in the same data center or region with low latency between them.
Write throughput doesn’t scale with nodes — every node applies every write.
Hot-spot writes to the same rows from different nodes cause certification conflicts (deadlock errors the app must retry). Many setups send all writes to one node and reads to all.
InnoDB only; tables need primary keys.

Requirements

Three nodes (or two plus an arbitrator, garbd) — an odd number keeps quorum when one fails.
Same MariaDB version on all nodes, private network between them.
Example IPs: 10.0.0.41, 10.0.0.42, 10.0.0.43.

1. Install MariaDB on all nodes

sudo apt update
sudo apt install -y mariadb-server mariadb-backup galera-4 rsync
sudo systemctl stop mariadb

2. Firewall (between nodes only)

Port	Use
3306/tcp	Client connections
4567/tcp+udp	Galera replication
4568/tcp	Incremental state transfer (IST)
4444/tcp	State snapshot transfer (SST)

for ip in 10.0.0.41 10.0.0.42 10.0.0.43; do
  sudo ufw allow from $ip to any port 3306,4444,4567,4568 proto tcp
  sudo ufw allow from $ip to any port 4567 proto udp
done

3. Galera configuration (all nodes)

/etc/mysql/mariadb.conf.d/60-galera.cnf:

[galera]
wsrep_on                 = ON
wsrep_provider           = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name       = "prod-cluster"
wsrep_cluster_address    = "gcomm://10.0.0.41,10.0.0.42,10.0.0.43"
wsrep_node_address       = "10.0.0.41"        # this node's IP
wsrep_node_name          = "db1"              # this node's name
wsrep_sst_method         = mariabackup
wsrep_sst_auth           = "sst:a-long-random-password"

binlog_format            = ROW
default_storage_engine   = InnoDB
innodb_autoinc_lock_mode = 2
bind-address             = 0.0.0.0

Change wsrep_node_address and wsrep_node_name on each node. Check the provider path on your system (dpkg -L galera-4 | grep libgalera).

SST (state snapshot transfer) copies the full data set to a node that joins or is too far behind. mariabackup does it without blocking the donor (unlike rsync). It needs a database user (created below).

4. Bootstrap the first node

The very first start creates a new cluster:

sudo galera_new_cluster        # on db1 only
sudo mysql -e "SHOW STATUS LIKE 'wsrep_cluster_size';"   # 1

Create the SST user on db1 (it replicates to the others once they join):

CREATE USER 'sst'@'localhost' IDENTIFIED BY 'a-long-random-password';
GRANT RELOAD, PROCESS, LOCK TABLES, BINLOG MONITOR ON *.* TO 'sst'@'localhost';

5. Start the other nodes

sudo systemctl start mariadb     # on db2, then db3

They join, receive an SST from a donor, and sync. On any node:

SHOW STATUS LIKE 'wsrep_cluster_size';          -- 3
SHOW STATUS LIKE 'wsrep_local_state_comment';   -- Synced
SHOW STATUS LIKE 'wsrep_ready';                 -- ON

Test: create a database on db2, see it on db1 and db3.

6. Connecting applications

Options:

Point the app at one node for writes (simplest; avoids conflicts), others for reads.
Put HAProxy or MaxScale/ProxySQL in front for health-checked routing — see HAProxy.
Use a floating IP with keepalived — see keepalived.

Quorum and recovery

If one of three nodes fails, the remaining two keep quorum and continue.
If the network splits 1–2, the single node becomes non-primary and refuses queries — protecting against split brain.
If all nodes go down (power loss, simultaneous restart), you must bootstrap from the most advanced node. Check /var/lib/mysql/grastate.dat on each: the node with safe_to_bootstrap: 1 (or the highest seqno) is bootstrapped with galera_new_cluster; the others then start normally.

Never bootstrap two nodes independently — you’d create two separate clusters with diverging data.

Maintenance tips

Restart nodes one at a time, waiting for Synced before the next.
Large ALTER TABLEs replicate as a total-order operation that blocks the cluster; plan schema changes carefully (consider wsrep_OSU_method=RSU or online schema tools).
Monitor wsrep_local_recv_queue, wsrep_flow_control_paused and cluster size.
Galera is not a backup — keep regular mariadb-backup or dump backups.

MariaDB
Galera
High Availability