MariaDB Galera Cluster

Introduction

1. Bénéfices

Comme nous avons pu le voir dans le chapitre précédent, le système de réplication natif de MariaDB est simple à mettre en place et permet de couvrir la plupart des besoins courants : scalabilité en lecture, haute disponibilité, redondance géographique, tests de nouvelles versions du serveur, et bien d’autres encore.

Néanmoins, nous avons pu constater que si la mise en place de la réplication est simple, son exploitation en conditions réelles se heurte à certaines difficultés dues à son caractère asynchrone. Par exemple, pour réellement pouvoir distribuer des lectures sur des esclaves de réplication, il est en général nécessaire de vérifier d’abord que le retard de réplication est en dessous d’un seuil acceptable. Sinon, le serveur risque de renvoyer des données périmées qui risquent de gêner le fonctionnement de l’application. Cas classique : vous ajoutez des produits dans votre panier sur un site de commerce en ligne (insertion d’enregistrements sur le serveur maître), et après avoir cliqué pour obtenir le récapitulatif de vos produits, vous aboutissez sur une page vide (lecture sur un serveur esclave ayant plusieurs secondes de retard sur le maître).

La situation est similaire en ce qui concerne la haute disponibilité : si l’existence d’un esclave de réplication permet, en théorie, facilement de n’avoir quasiment pas d’interruption de service si le maître devient indisponible, en pratique, reconfigurer tous les autres esclaves pour qu’ils aient connaissance du nouveau maître n’est pas toujours facile.

MariaDB Galera Cluster (que nous abrégerons à partir de maintenant MGC) a pour but principal de simplifier ces problèmes, en particulier celui de la haute disponibilité. Galera est un plug-in pour MariaDB, disponible également pour MySQL ou Percona Server, développé depuis la fin des années 2000 par la société Codership. Ce plug-in fournit un mécanisme de réplication qui peut être utilisé à la place du mécanisme de réplication natif de MariaDB. La particularité de la réplication...

Mise en place d’un cluster

1. Préparation de la configuration

La première étape consiste à obtenir MGC. À partir de MariaDB 10.1, Galera est inclus dans les paquets, vous n’aurez donc rien de particulier à installer. Mais si vous utilisez MariaDB 5.5 ou 10.0, vous devrez d’abord installer un paquet spécial à la place du paquet standard MariaDB (voir par exemple pour MariaDB 10.0 https://downloads.mariadb.org/mariadb-galera/10.0).

La seconde étape consiste à changer un certain de nombre de variables dans le fichier de configuration de MariaDB :

wsrep_provider : il faut indiquer le chemin complet vers le plug-in Galera. Par exemple sous Ubuntu, il s’agit normalement du fichier /usr/lib/galera/libgalera_smm.so.
wsrep_on = ON : pour activer la réplication Galera.
wsrep_cluster_address : il faut spécificier l’adresse IP de l’ensemble des nœuds Galera du cluster sous la forme gcomm://<IP nœud 1>,<IP nœud 2>,[...]. Pour le premier nœud, vous pouvez soit indiquer seulement gcomm:// ou préciser l’adresse IP du premier nœud (ou même l’adresse des futurs nœuds si elle est connue). Il est important de comprendre que les adresses IP indiquées dans cette variable ne sont utilisées qu’au moment du démarrage de MGC pour essayer de trouver d’éventuels...

Optimisation

1. Configuration

Galera offre de nombreuses variables de configuration, cependant la plupart peuvent être laissées à leur valeur par défaut. Nous allons nous concentrer dans cette section sur les paramètres qu’il est indispensable d’ajuster pour chaque cluster.

Outre celles mentionnées précédemment, les variables les plus importantes à modifier sont :

gcache.size : il s’agit de la taille du Galera cache. Si vous vous rappelez ce dont nous avons discuté dans l’introduction, quand un nœud rejoint le cluster, ses données sont synchronisées par rapport aux autres nœuds soit par IST (rapide, peu d’impact sur le nœud donneur) ou par un SST (lent, impact important sur le nœud donneur). Le choix entre ces deux méthodes se fait en fonction du Galera cache : si toutes les transactions manquantes du nœud qui rejoint le cluster se trouvent dans le Galera cache d’un autre nœud, l’IST sera automatiquement choisi. Il est donc important que le Galera cache soit suffisamment large pour éviter un SST dans la majorité des cas de figure. Ceci est d’autant plus important que le volume de données stocké par le cluster est élevé, car dans ce cas le SST sera d’autant plus coûteux. L’article suivant (en anglais) donne une manière simple de trouver une bonne taille pour le Galera cache : https://www.percona.com/blog/2014/09/08/calculate-correct-size-percona-xtradb-clusters-gcache/.
gcs.fc_limit : il s’agit du seuil à partir duquel le flow control est déclenché. Des explications détaillées sont fournies dans la section Éviter le flow control de ce chapitre.
wsrep_slave_threads : Galera offre la possibilité d’utiliser plusieurs threads pour appliquer les transactions reçues par la réplication. Si le trafic en écriture permet l’exécution en parallèle de plusieurs transactions, configurer plusieurs threads est un bon moyen pour faire en sorte que le flow control soit le plus rare possible (voir la suite de ce chapitre pour une explication détaillée sur le flow control). En général, configurer 4 à 8 threads est suffisant, mais si le processeur de votre serveur contient de nombreux cœurs...