Galera Cluster for MariaDB

In modern database man­age­ment solutions, con­tinu­ous operation, high avail­ab­il­ity, and flexible scaling options are all equally important. Without these char­ac­ter­ist­ics, it’s im­possible to handle fluc­tu­at­ing loads and un­ex­pec­ted peaks. Moreover, meeting these re­quire­ments while keeping in­fra­struc­ture costs to a minimum via cloud-based solutions is often a rather difficult balancing act.

Galera Cluster was designed with precisely these chal­lenges in mind. It is a multi-master clus­ter­ing solution for databases that uses high-per­form­ance syn­chron­ous rep­lic­a­tion to supply all the nodes of a database with the same data in real time. It ensures minimum data loss and high re­li­ab­il­ity and is available for MariaDB and other database man­age­ment systems. The following sections explain the ar­chi­tec­ture 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 clus­ter­ing ap­plic­a­tion is based on the InnoDB storage engine and its fork, XtraDB. There is also ex­per­i­ment­al support for the MyISAM engine that was used ex­tens­ively in MySQL and MariaDB before InnoDB was developed. When saving data in the various in­de­pend­ent cluster nodes, Galera Cluster uses the principle of syn­chron­ous rep­lic­a­tion. This means that all the rep­lic­a­tion processes and changes to stored data are carried out sim­ul­tan­eously 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 di­ver­gence between them.

A Galera Cluster contains at least three nodes, and the de­velopers generally recommend having an odd number of nodes. The reason for this is that if there’s a problem with a trans­ac­tion on one node (e.g. due to network problems or the system becoming un­re­spons­ive), the other two nodes will form a majority and can suc­cess­fully complete the trans­ac­tion.

In a MariaDB cluster based on Galera Cluster, all the nodes in the network have access to the same data at all times. In clus­ter­ing software, the con­ven­tion­al master/slave dis­tinc­tion 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 auto­mat­ic­ally be rep­lic­ated to all the other nodes in the cluster. This is known as a “multi-master” con­fig­ur­a­tion.

To manage this flexible exchange of data, Galera Cluster uses a syn­chron­ous cer­ti­fic­a­tion-based rep­lic­a­tion procedure. When data is rep­lic­ated (i.e. written to one of the databases in the cluster), Galera Cluster applies two basic prin­ciples:

1. A unique sequence number is assigned to each database trans­ac­tion. Before any node in the cluster commits the requested changes to the database, it compares this sequence number with the last committed trans­ac­tion. All nodes will always give the same result for the check (commit or abort). The node that initiated the trans­ac­tion can then notify the client of the outcome.
2. For each trans­ac­tion, all the database replicas are updated. Con­sequently, if a trans­ac­tion is committed after the cer­ti­fic­a­tion check, the cor­res­pond­ing changes will be made on all the nodes. A Galera Cluster node can only be excluded (tem­por­ar­ily) from the syn­chron­ous rep­lic­a­tion procedure if it has a technical problem.

As noted above, the main ad­vant­ages of the MariaDB Galera Cluster solution lie in the fact that the tech­no­logy combines flexible data storage with maximum re­li­ab­il­ity and avail­ab­il­ity – you won’t be able to achieve the same results with a standard MariaDB setup.

Thanks to the syn­chron­ous rep­lic­a­tion mechanism you no longer have to concern yourself with making sure that all the in­di­vidu­al storage units are up to date. Galera Cluster auto­mat­ic­ally updates each database unit with the latest changes which com­pletely elim­in­ates the need for making time-consuming manual copies and backups. Fur­ther­more, 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 ar­chi­tec­ture – the setup is ideal for flexible, cloud-based scaling of the database resources. Galera Cluster also makes it easy to dis­trib­ute data between different data centres because each trans­ac­tion only needs to be sent to each data centre once.

As we’ve seen, thanks to its char­ac­ter­ist­ics and benefits, a MariaDB Galera Cluster is an excellent solution for managing your database en­vir­on­ment. It’s par­tic­u­larly suited to the following use cases.

Dis­trib­ut­ing writes across the entire cluster optimises use of the available write resources. After the initial pro­cessing of a client trans­ac­tion, all the nodes to which this trans­ac­tion is sent only have to record the changes it contains. The overall write trans­ac­tion through­put of the Galera Cluster rep­lic­a­tion method is thus sig­ni­fic­antly higher than that of a standard database setup, making it an ideal solution for write-intensive ap­plic­a­tions.

The rep­lic­a­tion principle of Galera Cluster also works perfectly in a wide area network (WAN) like the internet. There will be some delay in trans­mis­sion (pro­por­tion­al to the round-trip time – RTT), but this will only affect the commit operation of the incoming database trans­ac­tions. 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 rep­lic­a­tion events but does not process client trans­ac­tions. If it is required for a recovery process, it is tem­por­ar­ily con­figured as the primary instance, which keeps downtime to a minimum.