Cluster setup

All STACKIT MariaDB cluster instances run in a synchronous multi-master (also known as multi-primary) replication setup. This is made possible through the use of MariaDB Galera Cluster. These cluster instances run under a quorum basis, which allows your cluster to be up and running as long as a majority is healthy.

MariaDB Galera cluster

MariaDB Galera Cluster is a multi-primary cluster for STACKIT MariaDB. This allows replication to happen at a transaction’s commit time, by broadcasting the write set associated with the transaction to every node in the cluster. MariaDB Galera Cluster also enables MariaDB clusters to function under a bidirectional replication, which means that all nodes in the MariaDB cluster are primaries. By default, you are provided a 3-node cluster with 3 primaries. MariaDB Galera Cluster also comes with the following features:

• Synchronous replication
• Active-active multi-primary topology
• Read and write to any cluster node
• Automatic membership control, failed nodes drop from the cluster
• Automatic node joining
• True parallel replication on row level

Replication

As mentioned above, the replication process on an STACKIT MariaDB cluster instance is possible via MariaDB Galera Cluster.

This can happen under 2 different methods:

• State Snapshot Transfers (SST)
• Incremental State Transfer (IST)

MariaDB Galera Cluster uses the SST method when a new node is being integrated into the cluster, or when a node has fallen behind and IST cannot recover the missing transactions. In a nutshell, this method provides a full data copy, which is provided by a node serving as a donor to the new/joining node.

Conversely, IST is preferred when the joining node already belonged to the cluster. This method works by identifying the missing transactions, and only sending said transactions instead of the full state. The only caveat, aside from previous membership, is that the missing write-set transactions should be available in the donor’s binary logs.

Cluster health logger

Periodically logs the wsrep and bin log status to /var/vcap/sys/log/cluster- health-logger/cluster_health.log.

Logged information summarizes the following queries:

SHOW STATUS WHERE Variable_name like 'wsrep%';
SHOW VARIABLES WHERE Variable_name = 'sql_log_bin';

The connection is made via the local socket.

GRA log purger

MariaDB creates files with the debug information for each replication error. These files are never deleted and therefore they can eventually occupy the whole disk. The gra-log-purger periodically checks for GRA log files older than 30 days and deletes them.

Galera healthcheck

Provides an HTTP API to retrieve the status of the Galera cluster. This API is only used by the internal components of the cluster.