Galera Cluster for MariaDB: an overview

In modern database management solutions, continuous operation, high availability, and flexible scaling options are all equally important. Without these characteristics, it’s impossible to handle fluctuating loads and unexpected peaks. Moreover, meeting these requirements while keeping infrastructure costs to a minimum via cloud-based solutions is often a rather difficult balancing act.

Galera Cluster was designed with precisely these challenges in mind. It is a multi-master clustering solution for databases that uses high-performance synchronous replication to supply all the nodes of a database with the same data in real time. It ensures minimum data loss and high reliability and is available for MariaDB and other database management systems. The following sections explain the architecture behind MariaDB Galera Clusters, what the benefits are and where the software is being used.

Galera Cluster is a software package for Linux operating systems that allows users to set up and manage MySQL, XtraDB, and MariaDB clusters. The clustering application is based on the InnoDB storage engine and its fork, XtraDB. There is also experimental support for the MyISAM engine that was used extensively in MySQL and MariaDB before InnoDB was developed. When saving data in the various independent cluster nodes, Galera Cluster uses the principle of synchronous replication. This means that all the replication processes and changes to stored data are carried out simultaneously on all the primary and secondary storage units so that the data is always up to date on all the nodes and there can be no divergence between them.

A Galera Cluster contains at leastthree nodes, and the developers generally recommend having an odd number of nodes. The reason for this is that if there’s a problem with a transaction on one node (e.g. due to network problems or the system becoming unresponsive), the other two nodes will form a majority and can successfully complete the transaction.

In a MariaDB cluster based on Galera Cluster, all the nodes in the network have access to the same data at all times. In clustering software, the conventional master/slave distinction for database servers (where the master is the server to which data can be written and the slaves are read-only servers) no longer exists. In other words, the user can write data to any of the storage nodes, and it will automatically be replicated to all the other nodes in the cluster. This is known as a “multi-master” configuration.

To manage this flexible exchange of data, Galera Cluster uses a synchronous certification-based replication procedure. When data is replicated (i.e. written to one of the databases in the cluster), Galera Cluster applies two basic principles:

1. A unique sequence number is assigned to each database transaction. Before any node in the cluster commits the requested changes to the database, it compares this sequence number with the last committed transaction. All nodes will always give the same result for the check (commit or abort). The node that initiated the transaction can then notify the client of the outcome.
2. For each transaction, all the database replicas are updated. Consequently, if a transaction is committed after the certification check, the corresponding changes will be made on all the nodes. A Galera Cluster node can only be excluded (temporarily) from the synchronous replication procedure if it has a technical problem.

As noted above, the main advantages of the MariaDB Galera Cluster solution lie in the fact that the technology combines flexible data storage with maximumreliability and availability – you won’t be able to achieve the same results with a standard MariaDB setup.

Thanks to the synchronous replication mechanism you no longer have to concern yourself with making sure that all the individual storage units are up to date. Galera Cluster automatically updates each database unit with the latest changes which completely eliminates the need for making time-consuming manual copies and backups. Furthermore, the multi-master setup means you can access any one of the linked MariaDB database servers when you want to write, edit or delete data, and since you can locate the nodes close to the clients, latency is kept to a minimum.

Another advantage of a MariaDB cluster based on Galera Cluster is that there is good cloud support for this architecture – the setup is ideal for flexible, cloud-based scaling of the database resources. Galera Cluster also makes it easy to distribute data between different data centres because each transaction only needs to be sent to each data centre once.

As we’ve seen, thanks to its characteristics and benefits, a MariaDB Galera Cluster is an excellent solution for managing your database environment. It’s particularly suited to the following use cases.

Distributing writes across the entire cluster optimises use of the available write resources. After the initial processing of a client transaction, all the nodes to which this transaction is sent only have to record the changes it contains. The overall write transaction throughput of the Galera Cluster replication method is thus significantly higher than that of a standard database setup, making it an ideal solution for write-intensive applications.

The replication principle of Galera Cluster also works perfectly in a wide area network (WAN) like the internet. There will be some delay in transmission (proportional to the round-trip time – RTT), but this will only affect the commit operation of the incoming database transactions. A MariaDB cluster is therefore a very sensible choice for cloud-based systems.

Anyone who stores and manages data in the cloud needs to consider data recovery. Thanks to Galera Cluster, data can be stored in a separate data centre so that a complete copy of the data is available for recovery purposes in the event of an emergency. In this setup, the recovery data centre of the MariaDB cluster receives replication events but does not process client transactions. If it is required for a recovery process, it is temporarily configured as the primary instance, which keeps downtime to a minimum.