MariaDB Server et MariaDB Cluster sont des produits open source alimentés par MariaDB Corporation. MariaDB Server est l'une des bases de données relationnelles les plus populaires, elle a été dérivée à l'origine du serveur MySQL.
MariaDB Cluster est une solution haute disponibilité construite à partir de MariaDB Server, utilisant une bibliothèque wsrep Galera Cluster pour synchroniser les données entre les nœuds. La méthode de réplication de Galera est synchrone (ou "virtuellement synchrone"), garantissant que les données seront les mêmes sur tous les nœuds.
Le serveur MariaDB peut également être rendu hautement disponible via une réplication standard. La réplication peut être asynchrone ou semi-synchrone.
En quoi le serveur MariaDB avec réplication standard diffère-t-il du cluster MariaDB avec Galera Cluster ? Dans ce blog, nous allons comparer ces deux. Nous utiliserons ClusterControl pour illustrer certaines des différences.
Architecture du serveur MariaDB
L'architecture de MariaDB Server peut être une instance unique/autonome ou une réplication maître/esclave, comme indiqué dans le schéma ci-dessous.
L'architecture à instance unique de MariaDB Server représente un seul nœud. L'inconvénient d'avoir une seule instance est un point de défaillance unique pour la base de données. Si votre base de données tombe en panne et ne revient pas, vous ne disposez d'aucun mécanisme de basculement et vous devez effectuer une restauration pour récupérer votre base de données à partir de la dernière sauvegarde.
L'architecture maître/esclave est une configuration distribuée, le maître jouant le rôle d'écrivain et le ou les esclaves de lecteur(s). À l'aide d'un équilibreur de charge comme Maxscale ou ProxySQL, vous pouvez diviser le trafic de la base de données afin que les écritures soient envoyées au maître et lues aux esclaves. Avoir une configuration de réplication éliminera un point de défaillance unique pour la base de données, mais vous devez être en mesure de basculer automatiquement si le maître échoue. Sinon, les applications ne pourront pas écrire dans la base de données et elles seront affectées. ClusterControl peut être configuré pour fournir un basculement et une récupération automatiques pour la réplication MariaDB.
Architecture de cluster MariaDB
MariaDB Cluster est une solution de haute disponibilité composée de MariaDB Server et Galera Replication comme indiqué dans le schéma d'architecture ci-dessous :
Il s'agit d'une réplication synchrone ("virtuellement synchrone"), tous les nœuds sont inscriptibles. La réplication synchrone garantit que si les modifications se produisent dans l'un des nœuds galera, elles seront disponibles sur tous les autres nœuds du cluster avant d'être validées.
La grande différence est que tous les nœuds sont égaux du point de vue de l'application, ils peuvent envoyer du trafic en écriture à n'importe quelle instance de la base de données. De plus, tous les nœuds doivent avoir exactement les mêmes données afin qu'il n'y ait pas de perte de données en cas de défaillance du nœud.
Déploiement MariaDB
La réplication MariaDB et le cluster MariaDB peuvent être déployés via ClusterControl. Lorsque vous déployez MariaDB Server, vous devez commencer par choisir MySQL Replication tandis que pour MariaDB Cluster, vous devez choisir MySQL Galera.
Pour MariaDB Server, vous pouvez soit déployer une instance MariaDB à nœud unique, soit configurer une réplication maître/esclave et bidirectionnelle. Le nombre minimum de nœuds dans une configuration de réplication est de deux, vous avez besoin d'un maître et d'au moins un esclave. Remplissez simplement l'adresse IP du maître et ajoutez des esclaves (si vous souhaitez avoir une architecture maître/esclave). Vous pouvez utiliser le champ Ajouter un deuxième maître si vous souhaitez configurer une réplication bidirectionnelle. Une configuration maître-maître sera provisionnée avec une réplication bidirectionnelle, mais l'un des nœuds sera défini en lecture seule. La raison est de minimiser le risque de dérive des données et de « transactions errantes ».
Pour MariaDB Cluster, vous avez besoin d'au moins 3 hôtes pour que les nœuds de la base de données cible être installé. En effet, il doit être capable de gérer le partitionnement du réseau ou le syndrome du «split brain». Il vous suffit de renseigner l'adresse IP lors de l'ajout d'un nœud lors de la définition de la configuration des serveurs MySQL.
N'oubliez pas de choisir MariaDB comme fournisseur de base de données, version de base de données qui vous voulez installer et remplissez le mot de passe root. Vous pouvez également remplacer le répertoire de données non par défaut par n'importe quel autre chemin.
Une fois que nous avons configuré toutes les choses, déployez simplement le cluster. Cela déclenchera une nouvelle tâche pour le déploiement de la base de données.
Notez qu'il est également possible d'avoir 2 nœuds Galera et un arbitre Galera alias garbd sur un troisième hôte.
Surveillance du serveur et du cluster MariaDB
La surveillance de la base de données est une partie essentielle de la base de données, vous pouvez connaître l'état actuel de la santé de la base de données. La différence entre la surveillance de MariaDB Server et de MariaDB Cluster est Galera Metrics pour la synchronisation.
Sur MariaDB Server, vous pouvez vérifier la santé actuelle de votre base de données via les métriques MySQL; MySQL Server - General, MySQL Server - Caches, MySQL InnoDB Metrics qui est également visible sur le cluster MariaDB comme indiqué ci-dessous :
MySQL Server - Général vous donne des informations sur l'état actuel du taux d'accès au pool de mémoire tampon InnoDB, de la connexion à la base de données, des requêtes, du verrouillage et de l'utilisation de la mémoire de la base de données.
Serveur MySQL - Caches, il y a beaucoup d'informations fournies dans Caches. Principalement lié à la mise en cache dans la base de données, par exemple :taille du pool de mémoire tampon, instance du pool de mémoire tampon. Il existe également des informations sur l'utilisation du cache de table, le taux de succès, les succès et les échecs du cache. Vous pouvez également trouver des informations sur l'utilisation du cache de thread et le taux d'accès .
Serveur MySQL - InnoDB Metrics affiche les métriques liées au stockage InnoDB, par exemple :l'activité du pool de mémoire tampon, les opérations sur les lignes InnoDB, la taille du fichier journal InnoDB, la lecture/écriture des données InnoDB.
Sur MariaDB Server, si vous configurez la réplication maître/esclave, il y en a une sous-catégorie de métriques sous MySQL Replication - Master. Il existe des informations relatives au fichier journal binaire principal, à la position du journal binaire principal et à la fréquence de création du journal binaire.
MariaDB Server contient de nombreuses informations relatives à la base de données, celles-ci sont également disponibles pour MariaDB Cluster. La différence est qu'il existe deux tableaux de bord pour MariaDB Cluster - Galera Overview et Galera Server Charts.
Galera Overview donne des informations relatives à l'état actuel de la réplication Galera. Il existe des informations telles que la taille du cluster, le contrôle de flux envoyé, le contrôle de flux reçu, le contrôle de flux suspendu.
Galera Server Charts contient des informations sur le nom du cluster, l'état du cluster, la taille, la taille du cache global.
Conclusion
MariaDB Server avec réplication standard et MariaDB Cluster ne sont pas vraiment des produits différents en termes de service de base de données, mais ils ont des caractéristiques différentes en fonction de vos exigences en matière de disponibilité et d'évolutivité. ClusterControl prend en charge à la fois le serveur MariaDB avec la réplication standard et les déploiements de cluster MariaDB, alors essayez les deux configurations et faites-nous part de vos réflexions.
