MariaDB Galera Cluster Made Easy: A Beginner’s Setup Guide

Introduction

As modern applications scale, databases face two critical challenges: high availability (HA) and data consistency. A single MariaDB server can become a bottleneck or worse — a single point of failure. If that server crashes, applications suffer downtime, which can mean lost revenue and poor user experience.

This is where MariaDB Galera Cluster comes in. It’s a synchronous multi-master cluster solution that ensures your database is always available, consistent, and fault-tolerant. Unlike traditional master-slave replication, every node in a Galera Cluster can accept read and write queries, and all nodes remain in sync.

Why choose Galera? (High-level advantages)

• High Availability (No single point of failure): If one node fails, other nodes continue serving queries.
• Multi-master writes: All nodes are writable; reads and writes can be served from any node.
• Strong consistency (certification-based): Transactions are replicated and certified before commit.
• Automatic node recovery: Nodes rejoin using IST (Incremental State Transfer) or SST (State Snapshot Transfer).
• No traditional slave lag: Because replication is certified synchronously, the classic master→slave lag pattern is avoided — but flow control can stall cluster progress when a node is slow. 
• Operational caveat: Many production teams intentionally use a single-writer pattern (pin writes to one node) to reduce certification conflicts and hot-row deadlocks while still distributing reads across the cluster.

Prerequisites for MariaDB Galera Cluster Setup

Before setting up a MariaDB Galera Cluster, you need to ensure that your environment is properly prepared. A well-planned setup avoids common issues like nodes failing to join or replication conflicts.

1.  Server Requirements
   • Minimum 3 nodes (recommended odd number of nodes → 3, 5, 7 for quorum).
   • OS: Ubuntu 20.04/22.04 LTS or CentOS 7/8 (RHEL supported).
   • CPU: At least 2 cores per node.
   • RAM: Minimum 4 GB, more if workload is heavy.
   • Storage: Use SSD for better I/O performance.
2. Software Requirements
   • MariaDB server with Galera support (MariaDB 10.5+ recommended).
   • Cluster communication handled via wsrep (Write Set Replication) library.
   • Time synchronization (e.g., NTP or chrony) enabled on all nodes to avoid replication conflicts.
3. Network Requirements
   • All nodes must communicate over:
   • TCP port 3306 → MySQL client connections.
   • TCP ports 4567 & 4568 → Galera cluster replication traffic.
   • TCP/UDP port 4444 → State Snapshot Transfer (SST).
   • Low-latency, high-bandwidth network recommended.
   • Assign a static IP address or DNS name to each node.
4. User & Authentication
   Create a dedicated MariaDB user for SST (State Snapshot Transfer) between nodes. Example:

CREATE USER 'sst_user'@'%' IDENTIFIED BY 'strongpassword';
GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'sst_user'@'localhost';
FLUSH PRIVILEGES;

Explanation of Galera Config Variables

• wsrep_on : Enables Galera replication. Without this, the MariaDB server runs as a normal standalone server.Helps avoid accidentally joining the wrong cluster.
   wsrep_on                 = ON
  
• wsrep_cluster_name : Logical name of the cluster.All nodes that want to join must use the same cluster name.
       wsrep_cluster_name       = "MariaDB Galera Cluster"
  
•  wsrep_provider : Path to the Galera replication provider library.This is the core component that handles synchronous replication between nodes.Default on Linux: /usr/lib/galera/libgalera_smm.so.
       wsrep_provider           = /usr/lib/galera/libgalera_smm.so

•  wsrep_cluster_address : The list of IP addresses of nodes in the cluster.Format: gcomm://IP1,IP2,IP3
              wsrep_cluster_address    = "gcomm://192.168.56.10,192.168.56.20,192.168.56.30"
  
  On the first node (bootstrap node), you start with:
          wsrep_cluster_address = "gcomm://"
      Then you start MariaDB with –wsrep-new-cluster.On the other nodes, you list all node IPs.
  
• Binlog_format : Sets the binary log format to ROW (row-based replication).Required by Galera for consistency, because statement-based replication can cause conflicts.
               binlog_format            = row
  
• default_storage_engine : Sets InnoDB as the default storage engine.Galera works only with InnoDB (or compatible engines).Other engines (e.g., MyISAM) are not safe in Galera.
                default_storage_engine   = InnoDB
  
•  Innodb_autoinc_lock_mode : Controls how AUTO_INCREMENT values are generated.2 = interleaved mode → recommended for Galera.Ensures that AUTO_INCREMENT works safely in multi-master mode.
    innodb_autoinc_lock_mode = 2
  
• bind-address : Makes MariaDB listen on all network interfaces.Required for external clients and other cluster nodes to connect.(If set to 127.0.0.1, only local connections are allowed).
     bind-address = 0.0.0.0
  
• wsrep_node_address : Specifies the IP address of this node.Used by other nodes to communicate with it.Must match the server’s real IP address (not 127.0.0.1).
      wsrep_node_address="192.168.56.10"
  

              Additional Galera Config Parameters

• wsrep_sst_method : Defines the method for State Snapshot Transfer (SST), i.e., how a new node copies the initial dataset from an existing node.
     wsrep_sst_method = rsync
  • Common options:
    • rsync → simple file copy (easy, but blocks donor node during transfer).
    • mariabackup → preferred in production (non-blocking, supports large datasets).
    • mysqldump → not recommended (slow, locks tables).
  • If not specified, the default is rsync.
    
• wsrep_sst_auth : Specifies the username:password for the SST process.Required when using mariabackup or mysqldump, because they connect through MariaDB.
        wsrep_sst_auth = sst_user:strongpassword
  
  Example user creation (on donor node):

CREATE USER 'sst_user'@'localhost' IDENTIFIED BY 'strongpassword';
GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'sst_user'@'localhost';
FLUSH PRIVILEGES;

Note:

• If you’re using rsync, this parameter is not needed.
• If you’re using mariabackup, this parameter is mandatory.

Setup Cluster configuration

1. Prerequisites

• Three servers (nodes) (e.g., 192.168.56.10, 192.168.56.20, 192.168.56.30)

• All nodes should:
  •  Have MariaDB (same version) installed.
  • Be able to communicate with each other over the network.

 In this guide, we will configure a MariaDB Galera Cluster (version 10.6.12) on Ubuntu using three Vagrant nodes.

2.Install MariaDB

On all three nodes:

sudo apt update
sudo apt -y install mariadb-server mariadb-client
sudo mysql_secure_installation

3.Update the /etc/hosts file

Edit the file using vi editor

  sudo vi /etc/hosts

Add the following lines to each node:

192.168.56.10  node1
192.168.56.20  node2
192.168.56.30  node3

4.Configure Galera on Each Node

Edit the config file (same for all nodes, except the server ID and IP):

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

Add the following (adjust IPs as per your environment):

[galera]
wsrep_on                 = ON
wsrep_cluster_name       = "MariaDB Galera Cluster"
wsrep_provider           = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_address    = "gcomm://192.168.56.10,192.168.56.20,192.168.56.30"
binlog_format            = row
default_storage_engine   = InnoDB
innodb_autoinc_lock_mode = 2
bind-address = 0.0.0.0
wsrep_node_address="192.168.56.10"

On each node, add a unique wsrep_node_address.

5. Start the Cluster

On the first node only (bootstrap the cluster):

sudo galera_new_cluster

Check the status of the writeset replication and cluster size.

show status like 'wsrep%';

On the other two nodes (join the cluster):

 sudo systemctl start mariadb

Check again on any node:

SHOW STATUS LIKE 'wsrep_cluster_size';

It should show 3.

6. Verify Cluster

Run on any node:

SHOW STATUS LIKE 'wsrep_cluster_status';
SHOW STATUS LIKE 'wsrep_connected';
SHOW STATUS LIKE 'wsrep_cluster_size';

Expected Output:

wsrep_cluster_status = Primary
wsrep_connected = ON
wsrep_cluster_size = 3

7. Test Replication

Create a database clust on the first node and check it to the other nodes.

create database clust;

First node

The database clust successfully created.

Check on Node2/Node3 the database is replicated or not

Second node:

Third node:

In the cluster setup   we have perform  read & write from any node.Here  create a new table in the cluster database from node2 and check the with the other nodes in the cluster.

Second node

Create table t1 for testing.

Check on Node1/Node3 the table is replicated or not.

First node

Third node

Conclusion

In this blog, we walked through the steps to configure a MariaDB Galera Cluster on Ubuntu, ensuring high availability and data consistency across multiple nodes. I hope this guide helps you get started with clustering and gives you the confidence to build more resilient and production-ready database systems.