MariaDB avec Galera Cluster : pré­sen­ta­tion du cluster

Le fonc­tion­ne­ment en continu et la dis­po­ni­bi­lité élevée sont in­dis­pen­sables aux solutions modernes de gestion de bases de données, au même titre que des pos­si­bi­li­tés de mise à l’échelle aussi flexibles que possible. C’est la seule façon de répondre aux exigences actuelles, avec des accès très fluc­tuants et des pointes de charge inat­ten­dues. Ce qui rend l’exercice périlleux, c’est de se conformer à ces attentes à l’aide du cloud tout en mi­ni­mi­sant les coûts d’in­fras­truc­ture.

Galera Cluster vous ac­com­pagne dans ce projet : cette solution cluster multi-maître pour les bases de données met en place une ré­pli­ca­tion très per­for­mante et synchrone pour alimenter tous les nœuds des serveurs d’une base de données en temps réel et avec les mêmes in­for­ma­tions. Dis­po­nible, entre autres, pour MariaDB, Galera Cluster garantit une perte de données minimale et une grande sécurité en cas de panne. Découvrez dans notre article comment fonc­tionne la mise en place de clusters MariaDB avec Galera Cluster, les avantages de cette tech­no­lo­gie et dans quels cas l’utiliser.

Galera Cluster est une suite lo­gi­cielle pour le système d’ex­ploi­ta­tion Linux per­met­tant la mise en place et la gestion de clusters pour MySQL, XtraDB et MariaDB. Cette ap­pli­ca­tion de cluster constitue la base du moteur de stockage d’InnoDB et de son fork XtraDB. À titre ex­pé­ri­men­tal, Galera Cluster supporte aussi le moteur MyISAM, utilisé depuis longtemps pour MySQL et MariaDB puisqu’il s’agit du pré­dé­ces­seur d’InnoDB. Lors de l’en­re­gis­tre­ment des données dans les dif­fé­rents nœuds de clusters in­dé­pen­dants, Galera Cluster utilise le principe de ré­pli­ca­tion synchrone : l’ensemble des processus de copie et des mo­di­fi­ca­tions appliqués aux données en­re­gis­trées est exécuté en même temps sur les unités de sau­ve­garde primaires et se­con­daires, afin que les données soient à jour à tout moment sur tous les nœuds et ne pré­sen­tent aucune dif­fé­rence les unes des autres.

Un Galera Cluster se compose au minimum de trois nœuds (les dé­ve­lop­peurs re­com­man­dent en général un nombre impair). Si l’un des nœuds rencontre un problème pendant une tran­sac­tion, par exemple à cause d’un problème de réseau ou d’un système dé­fec­tueux, les deux autres nœuds cons­ti­tuent une majorité in­dis­pen­sable pour permettre, malgré tout, l’exécution réussie de la tran­sac­tion.

Un cluster MariaDB basé sur Galera Cluster se distingue notamment par le fait que tous les nœuds du cluster affichent à tout moment le même niveau de mise à jour des données. La dif­fé­ren­cia­tion classique des serveurs de base de données employés, entre master (serveur en écriture) et slaves (serveurs en lecture seule) n’a plus cours avec ce logiciel de cluster : l’uti­li­sa­teur peut écrire des données sur n’importe quel nœud de sau­ve­garde, car ces dernières seront au­to­ma­ti­que­ment ré­pli­quées sur tous les autres com­po­sants du cluster. Cette propriété porte le nom de « multi-maître ».

Afin de sécuriser cet échange de données flexible, Galera Cluster ad­mi­nistre ses serveurs à l’aide d’un processus de ré­pli­ca­tion synchrone, qui s’appuie sur l’échange de cer­ti­fi­cats. Lorsque des données sont ré­pli­quées, donc inscrites sur une des bases de données du cluster, deux principes fon­da­men­taux s’ap­pli­quent avec le Galera Cluster de MariaDB :

1. Chaque tran­sac­tion sur une base de données se voit attribuer une séquence numérique unique. Avant d’autoriser les mo­di­fi­ca­tions cor­res­pon­dantes sur sa base de données, le nœud du cluster compare cette séquence numérique avec celle de la dernière tran­sac­tion appliquée. Grâce à ce contrôle, tous les nœuds arrivent sys­té­ma­ti­que­ment au même résultat (« tran­sac­tion acceptée » ou « tran­sac­tion refusée »). Le nœud ayant initié la tran­sac­tion le précise au client.
2. À chaque tran­sac­tion, toutes les répliques de la base de données sont ac­tua­li­sées. Si une tran­sac­tion est acceptée suite à la cer­ti­fi­ca­tion, tous les nœuds ap­pli­quent la mo­di­fi­ca­tion cor­res­pon­dante à leurs données. Si un nœud du Galera Cluster rencontre un problème technique, et uni­que­ment dans ce cas, il sera tem­po­rai­re­ment exclu de la ré­pli­ca­tion synchrone.

Nous avons déjà mentionné l’avantage décisif d’un cluster Galera pour MariaDB dans cet article : cette tech­no­lo­gie vous assure une sau­ve­garde flexible de vos données, tout en offrant une sécurité maximale en cas de panne et une haute dis­po­ni­bi­lité que l’on ne peut atteindre avec une con­fi­gu­ra­tion standard de MariaDB.

Grâce à la ré­pli­ca­tion synchrone, vous n’avez plus à vous inquiéter de l’état de mise à jour des unités de sau­ve­garde utilisées. Galera Cluster alimente au­to­ma­ti­que­ment chaque unité associée à une base de données avec les mo­di­fi­ca­tions les plus récentes, ce qui rend obsolètes la copie à la main et la mise en place de stra­té­gies de back-up fas­ti­dieuses. Le fonc­tion­ne­ment multi-maître permet également d’inscrire, de modifier ou de supprimer des données à partir de n’importe quel serveur de bases de données MariaDB associé. La pos­si­bi­lité de placer les nœuds à un endroit spé­ci­fique à proximité du client permet de minimiser la latence oc­ca­sion­née.

Autre avantage du cluster MariaDB basé sur Galera Cluster : l’ar­chi­tec­ture supporte très bien le cloud. C’est la meilleure solution que vous pourrez choisir pour une mise à l’échelle flexible sur le cloud des res­sources de vos bases de données. La ré­par­ti­tion des données sur plusieurs centres de calcul ne pose elle non plus aucun problème, car chaque tran­sac­tion dans Galera Cluster ne doit être envoyée qu’une seule fois à chaque centre de calcul.

Au vu de ses pro­prié­tés et de ses avantages, le cluster Galera MariaDB s’avère re­mar­quable pour ad­mi­nis­trer vos propres solutions de gestion de bases de données. Con­crè­te­ment, cette con­fi­gu­ra­tion de cluster a démontré son utilité dans les cas suivants :

La ré­par­ti­tion des processus d’écriture sur l’ensemble du cluster permet d’optimiser l’uti­li­sa­tion des res­sources en écriture dis­po­nibles. Après l’exécution d’une tran­sac­tion initiale du client, tous les nœuds auxquels cette tran­sac­tion doit être transmise intègrent seulement les mo­di­fi­ca­tions comprises dans cette tran­sac­tion. La méthode de ré­pli­ca­tion de Galera Cluster assure donc, dans l’ensemble, un débit d’écriture nettement plus rapide que celui de la con­fi­gu­ra­tion ha­bi­tuelle de votre base de données, ce qui rend la tech­no­lo­gie des clusters par­ti­cu­liè­re­ment in­té­res­sante pour les ap­pli­ca­tions avec un fort débit d’écriture.

Le principe de ré­pli­ca­tion synchrone de Galera Cluster fonc­tionne également sans problème sur un WAN (Wide Area Network) comme Internet. On constate cependant un petit delay (délai de trans­mis­sion) pro­por­tion­nel au temps de trans­mis­sion total des paquets (RTT) du réseau. Ce délai porte uni­que­ment sur le processus de con­fir­ma­tion des tran­sac­tions de base de données entrantes. Un cluster MariaDB sur le cloud offrira par con­sé­quent une solution par­ti­cu­liè­re­ment in­té­res­sante.

En lien étroit avec la sau­ve­garde et l’ad­mi­nis­tra­tion plus générales des mises à jour des données sur le cloud, citons le principe de Disaster Recovery, qui préconise de stocker les données dans un centre de calcul in­dé­pen­dant afin de disposer, en cas de panne, d’une image des données pour la res­tau­ra­tion. Dans ce cas, Galera Cluster peut certes rediriger les données de ré­pli­ca­tion, mais ne permet pas leur mo­di­fi­ca­tion par une tran­sac­tion du client. Si la res­tau­ra­tion s’avère né­ces­saire, la partition Disaster Recovery du cluster MariaDB est tem­po­rai­re­ment déclarée comme instance primaire afin de réduire au maximum le temps de dé­fail­lance.