MariaDB and MariaDB Cluster: complete guide

What are MariaDB and MariaDB Galera Cluster?

MariaDB is a relational database management system (RDBMS), whileMariaDB Cluster is a synchronous, multi-master cluster for MariaDB databases.

Why use Galera Cluster?

Galera Cluster offers numerous features such as automatic node joining, synchronous replication, direct client connections, active-active multi-master topology, and true row-level parallel replication.

MariaDB Cluster, developed in collaboration with Codership, is currently in its Alpha quality stage but is already successfully used by many with great results.

For modern database management solutions, high availability and continuous operation are crucial, along with flexible scalability options. Galera Cluster is the ideal solution for handling fluctuating access levels and unexpected traffic spikes, even with limited infrastructure costs. As a high-performance synchronous replication solution, it ensures that all nodes in the database network receive the same data in real-time.

Galera Cluster, available not only for MariaDB but also for other systems, guarantees top-level reliability with minimal data loss.

Scalability requirements

During normal operations, the memory usage of a MariaDB Galera node is comparable to a typical MariaDB server. However, memory usage may increase with larger modification sets and certification indexes. Typically, applications will not notice this difference.

When a state transfer is received by a node, it cannot process incoming modification sets as no state is available for them to apply. Modifications need to be cached for later application during catch-up. If memory is exhausted, the state transfer may fail, or the cluster may stall while awaiting the completion of the transfer.

Galera Cluster software package

MariaDB Galera Cluster is a software package for building and managing MariaDB, XtraDB, and MySQL clusters on Linux operating systems. Based on the InnoDB storage engine, it enables synchronous replication across independent cluster nodes, ensuring real-time data consistency.

A basic cluster consists of three nodes, and it is generally recommended to maintain an odd number of nodes. In case one node fails during a data transaction due to system or network issues, the remaining nodes ensure smooth completion of the transaction.

Key features of MariaDB Cluster powered by Galera Cluster

The main characteristic of a MariaDB cluster using Galera Cluster is that all nodes in the network have identical data. The traditional distinction between master and slave servers—read-only vs. writable servers—is eliminated. Users can write data to any storage node, and the data is automatically synchronized with the other nodes. This is known as a multi-master setup.

Setting Up a Basic Galera Cluster

The three nodes of a basic Galera cluster each run MariaDB with a handful of extra settings in /etc/mysql/mariadb.conf.d/50-server.cnf (or galera.cnf, depending on the distribution). The core parameters that turn a standalone MariaDB instance into a cluster node are:

[galera]
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://node1_ip,node2_ip,node3_ip"
wsrep_cluster_name="cluster_produzione"
wsrep_sst_method=mariabackup
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2

The first node is bootstrapped on its own (gcomm:// with no addresses, or the distribution's galera_new_cluster command), after which the other two join by pointing at the cluster address above; on a running cluster, restarting a node simply has it request a State Snapshot Transfer (SST) from an existing node to catch up.

Errors You'll Actually Run Into

• A node won't join and stays in "Initialized" or "Joining" state — usually a full State Snapshot Transfer (SST) is happening, and on a database of any real size this can take from minutes to hours; check the donor node's error log rather than assuming the joining node is broken.
• wsrep_sst_method fails partway through — mariabackup (the modern default) needs write access to the joining node's data directory and enough free disk space for a full copy of the dataset; running out of disk mid-transfer is the most common cause of a stuck or failed SST.
• Cluster stuck in "non-Primary" state after a network split — Galera uses quorum (a strict majority of nodes) to decide which side of a network partition is allowed to keep accepting writes; with only two nodes there's no way to break a tie, which is exactly why three (or another odd number) is the recommended minimum, not just a suggestion.
• A node keeps getting evicted from the cluster — often a network latency or firewall issue between nodes rather than a MariaDB problem: Galera's replication is synchronous, so a consistently slow link between two sites is a poor fit for it (a stretched cluster across two offices, over a VPN, is one of the more common reasons we see for a cluster becoming unstable).

Backing Up a Galera Cluster

Because every node holds identical data, in principle a backup can be taken from any single node using mariabackup (the tool also used for SST) or the same mysqldump approach used for a standalone MariaDB server. In practice, it's worth designating one specific node for backup jobs and, where possible, running them against a node temporarily desynced from the cluster (SET GLOBAL wsrep_desync=ON) to avoid the backup's I/O load affecting write performance on the rest of the cluster.

When Galera Cluster Is (and Isn't) the Right Choice

A synchronous multi-master cluster solves a real problem — no single point of failure, and any node can accept writes — but it comes at the cost of write latency (every commit has to be certified across all nodes) and real operational complexity: three servers to patch and monitor instead of one, and a genuine risk of a stuck SST or a quorum split if the underlying network isn't solid. For a business running a single application against a database that a few minutes of downtime and a restore from backup can tolerate, a standard MariaDB instance with regular backups is usually the simpler, more maintainable choice. Galera earns its complexity when the database itself can't be a single point of failure — for example behind a customer-facing service that has to stay reachable even while one server is being patched or has failed outright.

The solution just a click away!

Need help with MariaDB Cluster or having trouble using it? Contact us! The @tnsolutions.it team is ready to provide all the IT support you need.