Setup MariaDB Galera Cluster on Ubuntu VPS: Multi-Master Setup

Understanding MariaDB Galera Cluster Architecture

MariaDB Galera Cluster delivers synchronous multi-master replication for high availability database deployments. Every node accepts both read and write operations, unlike traditional master-slave configurations. This makes it perfect for distributed applications that can't tolerate downtime.

Galera uses certification-based replication. All nodes validate transactions before committing. This ensures data consistency across the cluster while providing automatic failover.

For hosting environments, Galera clusters eliminate single points of failure. Your Hostperl VPS instances maintain database availability even when one or more nodes experience problems.

Prerequisites and System Requirements

Before you setup MariaDB Galera cluster, verify each Ubuntu VPS meets these requirements:

• Ubuntu 22.04 LTS or later
• Minimum 2GB RAM per node (4GB recommended)
• At least 3 nodes for proper quorum
• Stable network connectivity between nodes
• Synchronized system clocks via NTP

Plan your cluster topology carefully. Odd numbers of nodes prevent split-brain scenarios.

For production, distribute nodes across different availability zones. Keep network latency between nodes under 10ms for optimal performance. Higher latencies increase transaction commit times and hurt application responsiveness.

Installing MariaDB and Galera Components

Install MariaDB and Galera packages on all cluster nodes:

sudo apt update
sudo apt install mariadb-server mariadb-backup galera-4 rsync

Stop the MariaDB service before configuring cluster settings:

sudo systemctl stop mariadb

Install additional packages for monitoring and troubleshooting:

sudo apt install socat pv netcat-openbsd

Verify the installation by checking versions:

mariadb --version
galera_recovery --version

Configuring Galera Cluster Settings

Create the Galera configuration file on each node. Replace the default MariaDB configuration with cluster-specific settings:

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

Add this configuration (adjust IP addresses for your environment):

[galera]
# Mandatory settings
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_name="production_cluster"
wsrep_cluster_address="gcomm://10.0.0.101,10.0.0.102,10.0.0.103"

# Node-specific settings (change for each node)
wsrep_node_address="10.0.0.101"
wsrep_node_name="node1"

# Replication settings
wsrep_sst_method=rsync
wsrep_sst_auth="sstuser:secure_password"

# Performance tuning
wsrep_slave_threads=4
wsrep_retry_autocommit=3

Update the node-specific settings for each server. Node2 uses `10.0.0.102` and `node2`. Node3 uses `10.0.0.103` and `node3`.

Initializing the First Cluster Node

Bootstrap the cluster from the first node:

sudo galera_new_cluster

This command initializes the cluster with a single node. Check the cluster status:

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_%';"

Key status variables to verify:

• `wsrep_cluster_size` should equal 1
• `wsrep_ready` should be ON
• `wsrep_local_state_comment` should show "Synced"

Create the SST (State Snapshot Transfer) user for node synchronization:

mysql -u root -p
CREATE USER 'sstuser'@'localhost' IDENTIFIED BY 'secure_password';
GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost';
FLUSH PRIVILEGES;

Adding Additional Nodes to the Cluster

Start MariaDB on the second and third nodes normally:

sudo systemctl start mariadb

The nodes will automatically join the cluster and synchronize data from existing members. Monitor the join process:

tail -f /var/log/mysql/error.log | grep -i galera

Successful joining shows messages like "SST complete" and "Member synced". Verify cluster membership from any node:

mysql -u root -p -e "SELECT * FROM information_schema.GLOBAL_STATUS WHERE VARIABLE_NAME IN ('wsrep_cluster_size', 'wsrep_local_state_comment', 'wsrep_ready');"

All nodes should report `wsrep_cluster_size` equal to your total node count (3 in this example).

For hosting customers managing multiple database environments, traditional MySQL replication setups offer simpler alternatives for specific use cases.

Cluster Security and Access Control

Secure your Galera cluster by configuring proper authentication and encryption. Enable SSL for cluster communication:

[galera]
wsrep_provider_options="socket.ssl_key=/etc/mysql/ssl/server-key.pem;socket.ssl_cert=/etc/mysql/ssl/server-cert.pem;socket.ssl_ca=/etc/mysql/ssl/ca-cert.pem"

Generate SSL certificates for secure node communication:

sudo mysql_ssl_rsa_setup --datadir=/var/lib/mysql

Configure firewall rules to allow Galera ports between cluster nodes:

sudo ufw allow from 10.0.0.0/24 to any port 3306
sudo ufw allow from 10.0.0.0/24 to any port 4567
sudo ufw allow from 10.0.0.0/24 to any port 4568
sudo ufw allow from 10.0.0.0/24 to any port 4444

These ports handle MySQL connections (3306), Galera communication (4567), IST transfers (4568), and SST transfers (4444).

Testing Multi-Master Functionality

Verify that all nodes accept write operations by creating test data.

On Node 1:

mysql -u root -p
CREATE DATABASE cluster_test;
USE cluster_test;
CREATE TABLE test_node1 (id INT PRIMARY KEY, node VARCHAR(10));
INSERT INTO test_node1 VALUES (1, 'node1');

On Node 2:

mysql -u root -p
USE cluster_test;
INSERT INTO test_node1 VALUES (2, 'node2');
CREATE TABLE test_node2 (id INT PRIMARY KEY, data VARCHAR(50));

Verify data synchronization across all nodes:

mysql -u root -p -e "SELECT * FROM cluster_test.test_node1; SHOW TABLES FROM cluster_test;"

Each node should display identical results, confirming successful multi-master replication.

Performance Monitoring and Optimization

Monitor cluster performance using Galera-specific status variables. Key metrics include:

mysql -u root -p -e "SHOW STATUS WHERE Variable_name IN ('wsrep_flow_control_paused', 'wsrep_cert_deps_distance', 'wsrep_apply_window');"

Optimize cluster performance by adjusting these parameters:

# In galera configuration
wsrep_slave_threads=8  # Number of CPU cores
innodb_buffer_pool_size=2G  # 70% of available RAM
innodb_log_file_size=256M

Monitor replication lag using:

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_local_recv_queue_avg';"

Values consistently above 1.0 indicate performance bottlenecks requiring investigation.

For comprehensive server monitoring including database clusters, review our automated backup strategies to protect your clustered data.

Backup Strategies for Galera Clusters

Implement consistent backup procedures across your cluster. Use MariaBackup for non-blocking backups:

sudo mariabackup --backup --target-dir=/backup/galera-$(date +%Y%m%d) --user=root --password=your_password

Schedule automated backups from a single node to avoid resource conflicts:

#!/bin/bash
# Galera cluster backup script
BACKUP_DIR="/backup/galera-$(date +%Y%m%d-%H%M)"
mkdir -p $BACKUP_DIR

mariabackup --backup --target-dir=$BACKUP_DIR --user=backup_user --password=backup_password

if [ $? -eq 0 ]; then
    echo "Backup completed: $BACKUP_DIR"
    # Compress and transfer to remote storage
    tar czf $BACKUP_DIR.tar.gz $BACKUP_DIR
    rm -rf $BACKUP_DIR
else
    echo "Backup failed"
fi

Store backups externally to protect against site-wide failures affecting your entire cluster.

Frequently Asked Questions

How many nodes should I use in a Galera cluster?

Use an odd number of nodes (3, 5, or 7) to prevent split-brain scenarios. Three nodes provide sufficient redundancy for most applications while maintaining manageable complexity.

What happens if the cluster loses quorum?

When less than half the nodes are available, the cluster becomes read-only to prevent data conflicts. Restore quorum by bringing failed nodes back online or manually bootstrapping from the largest partition.

Can I run Galera cluster across different geographic regions?

Yes, but network latency significantly impacts performance. Keep latency under 10ms for production workloads. Consider using asynchronous replication between regions instead.

How do I handle schema changes in Galera cluster?

Execute DDL statements on any node - they replicate automatically. For large schema changes, consider using pt-online-schema-change to minimize locking impact across the cluster.

What's the difference between IST and SST in Galera?

IST (Incremental State Transfer) sends only missing transactions to nodes that were briefly disconnected. SST (State Snapshot Transfer) provides complete database copies for nodes joining fresh or after extended downtime.