Galera Cluster for MariaDB

In modern database man­age­ment solutions, con­tin­u­ous operation, high avail­abil­i­ty, and flexible scaling options are all equally important. Without these char­ac­ter­is­tics, it’s im­pos­si­ble to handle fluc­tu­at­ing loads and un­ex­pect­ed 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­for­mance syn­chro­nous repli­ca­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­a­bil­i­ty 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­pli­ca­tion is based on the InnoDB storage engine and its fork, XtraDB. There is also ex­per­i­men­tal support for the MyISAM engine that was used ex­ten­sive­ly in MySQL and MariaDB before InnoDB was developed. When saving data in the various in­de­pen­dent cluster nodes, Galera Cluster uses the principle of syn­chro­nous repli­ca­tion. This means that all the repli­ca­tion processes and changes to stored data are carried out si­mul­ta­ne­ous­ly 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­vel­op­ers 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­spon­sive), the other two nodes will form a majority and can suc­cess­ful­ly 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 au­to­mat­i­cal­ly be repli­cat­ed to all the other nodes in the cluster. This is known as a “multi-master” con­fig­u­ra­tion.

To manage this flexible exchange of data, Galera Cluster uses a syn­chro­nous cer­ti­fi­ca­tion-based repli­ca­tion procedure. When data is repli­cat­ed (i.e. written to one of the databases in the cluster), Galera Cluster applies two basic prin­ci­ples:

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­se­quent­ly, if a trans­ac­tion is committed after the cer­ti­fi­ca­tion check, the cor­re­spond­ing changes will be made on all the nodes. A Galera Cluster node can only be excluded (tem­porar­i­ly) from the syn­chro­nous repli­ca­tion procedure if it has a technical problem.

As noted above, the main ad­van­tages of the MariaDB Galera Cluster solution lie in the fact that the tech­nol­o­gy combines flexible data storage with maximum re­li­a­bil­i­ty and avail­abil­i­ty – you won’t be able to achieve the same results with a standard MariaDB setup.

Thanks to the syn­chro­nous repli­ca­tion mechanism you no longer have to concern yourself with making sure that all the in­di­vid­ual storage units are up to date. Galera Cluster au­to­mat­i­cal­ly updates each database unit with the latest changes which com­plete­ly elim­i­nates 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 centers because each trans­ac­tion only needs to be sent to each data center once.

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

Dis­trib­ut­ing writes across the entire cluster optimizes use of the available write resources. After the initial pro­cess­ing 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 repli­ca­tion method is thus sig­nif­i­cant­ly higher than that of a standard database setup, making it an ideal solution for write-intensive ap­pli­ca­tions.

The repli­ca­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 center 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 center of the MariaDB cluster receives repli­ca­tion events but does not process client trans­ac­tions. If it is required for a recovery process, it is tem­porar­i­ly con­fig­ured as the primary instance, which keeps downtime to a minimum.