MariaDB Galera Cluster Setup: Multi-Master Database Replication on Bare Metal

When a single database server goes down, everything built on top of it goes down too. That's the problem MariaDB Galera Cluster solves. Instead of one master database with read replicas, Galera gives you synchronous multi-master replication — every node in the cluster can accept both reads and writes, and every write is committed to all nodes before it's confirmed. If one node fails, the others keep serving traffic without any manual failover step.

Running this kind of cluster on shared cloud instances is possible, but synchronous replication is sensitive to network latency and disk I/O — exactly the two things a busy shared host can't guarantee. A bare metal dedicated server gives each node dedicated CPU, RAM, and disk throughput, so write certification between nodes stays fast and predictable. This guide walks through setting up a 3-node MariaDB Galera Cluster from scratch.

Why Use Galera Cluster Instead of Standard Replication?

Standard MySQL/MariaDB master-slave replication is asynchronous — the master doesn't wait for a replica to confirm before considering a write complete. That's fine for read scaling, but if the master fails, you can lose the most recent transactions and need a manual (or scripted) failover.

Galera Cluster is different:

• Multi-master — write to any node, not just one

• Synchronous replication — a transaction only commits once every node agrees on it, so there's no data loss on failover

• Automatic node recovery — a node that rejoins the cluster automatically syncs itself back up to date

• No single point of failure — the application layer can send traffic to whichever node is healthy

This makes Galera a strong fit for e-commerce platforms, SaaS applications, and anything else where downtime or data loss is not acceptable. For a deeper look at business impact, see our guide on database high availability.

Prerequisites

You'll need three separate bare metal servers, each with:

• Ubuntu 22.04 LTS installed

• A minimum of 4 CPU cores and 8GB RAM (more for production write-heavy workloads)

• A private network connection between the three nodes — low latency here matters a lot, since Galera confirms every write across all nodes synchronously

• Root or sudo SSH access

• Static internal IP addresses assigned to each server

Since node-to-node latency directly affects write speed, keeping all three servers in the same data centre location is important. eServers' UK data centre locations — including London, Manchester, and Slough — let you deploy multiple bare metal nodes on the same low-latency network, which is exactly what synchronous replication needs to perform well.

Step 1: Install MariaDB and Galera Packages on All Three Nodes

Run the following on all three servers:

sudo apt update
sudo apt install -y mariadb-server mariadb-client galera-4 rsync
                            

galera-4 provides the wsrep replication library that MariaDB uses to talk to other nodes in the cluster. rsync is used for State Snapshot Transfer (SST) when a node needs to sync its full dataset from another node.

Step 2: Stop MariaDB Before Configuring the Cluster

sudo systemctl stop mariadb
                            

Galera settings need to be in place before the service starts for the first time as a cluster member.

Step 3: Configure the Galera Cluster File

On all three nodes, edit the Galera configuration file:

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

Add the following, adjusting the IP addresses and node name for each server:

[galera]
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name = "production_cluster"
wsrep_cluster_address = "gcomm://10.0.0.11,10.0.0.12,10.0.0.13"

binlog_format = ROW
default_storage_engine = InnoDB
innodb_autoinc_lock_mode = 2

wsrep_sst_method = rsync
wsrep_node_address = "THIS_NODE_IP"
wsrep_node_name = "node1"
                            

Replace THIS_NODE_IP with the actual IP of the server you're editing, and wsrep_node_name with node1, node2, or node3 respectively. Keep wsrep_cluster_address identical across all three nodes — it lists every member of the cluster.

Step 4: Open the Required Firewall Ports

Galera needs four ports open between the nodes: 3306 (MySQL), 4567 (cluster replication), 4568 (IST — incremental state transfer), and 4444 (SST — state snapshot transfer). Run this on all three servers, allowing traffic only from the other nodes' IPs:

sudo ufw allow from 10.0.0.11 to any port 3306,4567,4568,4444 proto tcp
sudo ufw allow from 10.0.0.12 to any port 3306,4567,4568,4444 proto tcp
sudo ufw allow from 10.0.0.13 to any port 3306,4567,4568,4444 proto tcp
sudo ufw enable
                            

If the cluster will ever need to be reached from outside this private network, put it behind DDoS protection rather than exposing database ports directly to the internet.

Step 5: Bootstrap the First Node

The cluster needs to be initialised from one node before the others can join. On Node 1 only, run:

sudo galera_new_cluster
                            

This starts MariaDB on Node 1 as a cluster of one. Verify it's running as expected:

sudo mysql -u root -e "SHOW STATUS LIKE 'wsrep_cluster_size';"
                            

You should see wsrep_cluster_size = 1.

Step 6: Join Node 2 and Node 3 to the Cluster

On Node 2 and Node 3, start MariaDB normally — since wsrep_cluster_address already points to Node 1, each server will perform a full State Snapshot Transfer and sync its data automatically:

sudo systemctl start mariadb
                            

Check the cluster size again from any node:

sudo mysql -u root -e "SHOW STATUS LIKE 'wsrep_cluster_size';"
                            

Once all three nodes are up, this should return 3.

Step 7: Secure the Installation

Run the standard MariaDB hardening script on each node to set a root password, remove anonymous users, and disable remote root login:

sudo mysql_secure_installation
                            

Step 8: Test Multi-Master Writes

Create a test database on Node 1:

CREATE DATABASE galera_test;
USE galera_test;
CREATE TABLE demo (id INT PRIMARY KEY, note VARCHAR(50));
INSERT INTO demo VALUES (1, 'written on node 1');
                            

Then check Node 2 and Node 3 — the row should already be there, confirming synchronous replication is working:

SELECT * FROM galera_test.demo;
                            

Try inserting a row directly on Node 2 as well, to confirm every node accepts writes, not just Node 1.

Step 9: Set Up Load Balancing (Optional but Recommended)

Since all three nodes can accept writes, most production setups place a load balancer such as HAProxy or ProxySQL in front of the cluster, so your application connects to a single address and traffic is distributed automatically if a node goes down. This also lets you take a node offline for maintenance without any downtime for your application.

Step 10: Monitor Cluster Health

A few status variables are worth checking regularly:

SHOW STATUS LIKE 'wsrep_cluster_status';   -- should be 'Primary'
SHOW STATUS LIKE 'wsrep_ready';            -- should be 'ON'
SHOW STATUS LIKE 'wsrep_local_state_comment'; -- should be 'Synced'
                            

If a node reports anything other than Synced, it's either recovering from a network split or performing a state transfer, and shouldn't be sent live traffic until it catches up.

Performance Notes for Bare Metal Deployments

Galera's synchronous replication makes disk I/O and network latency the two biggest performance factors:

• Fast local storage on each node reduces commit latency, since InnoDB has to flush transactions before Galera can certify them across the cluster.

• A dedicated, low-latency network between nodes — ideally within the same data centre — keeps write certification quick even under heavy concurrent load.

• Consistent hardware across all three nodes avoids one slower node becoming a bottleneck for the whole cluster, since Galera's write performance is only as fast as its slowest member.

This is where bare metal has a clear edge over shared virtual machines: with AMD EPYC or Intel Xeon dedicated servers, you get consistent, dedicated resources on every node, so the cluster behaves predictably instead of being affected by other tenants on the same host.

Wrapping Up

A properly configured MariaDB Galera Cluster removes the single point of failure that a standalone database server represents, while giving you true multi-master writes and automatic node recovery. Running it on bare metal — rather than shared cloud VMs — keeps the synchronous replication that Galera depends on fast and consistent, since network latency and disk I/O are no longer shared with other tenants.

If you're planning a production Galera deployment, eServers' bare metal dedicated servers across multiple UK data centres give you the dedicated, low-latency infrastructure this kind of cluster needs, backed by 24/7 UK-based support if you run into issues along the way.