Installer et configurer un cluster Galera pour MySQL/MariaDB sur Ubuntu/Debian et CentOS/RHEL

  Administration système Linux, Bases de données
installation et configuration un cluster Galera à deux nœuds pour MySQL

Introduction

Galera Cluster permet de construire un cluster de bases de données MySQL / MariaDB hautement disponible sans compromettre la cohérence des données. En répliquant les données entre les nœuds en temps réel, Galera assure une disponibilité continue même en cas de défaillance de nœuds individuels.

Dans ce tutoriel complet, nous allons parcourir les étapes de configuration d’un cluster Galera à deux nœuds sur Ubuntu/Debian et CentOS/RHEL Linux.

Prérequis

Avant de commencer, assurez-vous de disposer de:

  • 2 serveurs ou VM avec Ubuntu 18.04+/Debian 9+ ou CentOS 7+/RHEL 7+ installés.
  • Au moins 2 Go de RAM et 2 cores de CPU sur chaque nœud.
  • Accès root aux serveurs via SSH.
  • MySQL server déjà installé sur les deux nœuds. Version 5.7+ recommandée.
  • Règles de pare-feu de base configurées pour autoriser le trafic sur les ports 3306, 4567, 4568 et 4444.

Nous exécuterons la plupart des commandes en tant qu’utilisateur root ou avec les privilèges sudo.

Installation de Galera et des packages associés

Nous commençons par installer le logiciel Galera Cluster et d’autres utilitaires nécessaires au bon fonctionnement du cluster.

Sur Ubuntu/Debian

Mettre à jour les indexes des dépôts apt et installer les paquets requis :

$ apt update
$ apt install galera-4 mariadb-server socat python3-mysql.connector

Ceci installe:

  • galera-4 – frameworks Galera Cluster
  • mariadb-server – Pour le serveur de bases de données MySQL
  • socat – Pour tester et surveiller les clusters
  • python3-mysql.connector – Pour les connexions MySQL depuis Python

Sur CentOS/RHEL

Activez les dépôts EPEL qui fournissent les paquets Galera :

$ yum install epel-release

Maintenant, installez Galera et ses dépendances :

$ yum install galera mariadb-server rsync socat mysql-connector-python

Ceci installe:

  • galera – Galera Cluster
  • mariadb-server – Le serveur MySQL
  • rsync – Pour les transferts d’instantanés SST
  • socat – Utilitaire de surveillance
  • mysql-connector-python – Connecteur Python pour MySQL

Galera Cluster est maintenant prêt à être configuré sur les deux nœuds.

Configuration de MySQL pour Galera

Pour que MySQL utilise Galera, nous devons configurer quelques options dans my.cnf.

Ouvrez le fichier de configuration :

$ nano /etc/my.cnf

Ajoutez ce qui suit sous [mysqld] :

binlog_format=ROW
default-storage-engine=innodb 
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0
  
# Paramètres Galera 
wsrep_provider=/usr/lib64/galera-4/libgalera_smm.so
wsrep_cluster_name='my_galera_cluster'
wsrep_cluster_address="gcomm://node1,node2"
# Ceci uniquement sur le nœud 1
wsrep_node_address='192.168.1.101'
wsrep_node_name='node1'
# Ceci uniquement sur le nœud 2
wsrep_node_address='192.168.1.102' 
wsrep_node_name='node2'
wsrep_sst_method=rsync

Le wsrep_cluster_address contient la liste des adresses IP des nœuds du cluster.

wsrep_node_address et wsrep_node_name doivent être uniques sur chaque serveur.

Enregistrez et fermez le fichier après avoir fait les changements.

Faites ceci sur les deux serveurs, en remplaçant les IP et noms selon vos serveurs.

Cela configure MySQL pour utiliser le plugin Galera pour la réplication.

Démarrage du cluster Galera

La configuration étant en place, nous sommes prêts à démarrer le cluster.

Démarrez MySQL uniquement sur le premier nœud (node1) :

$ systemctl start mysql
# ou
$ systemctl start mariadb

Ceci va initialiser le cluster Galera.

Vérifiez le statut MySQL et les variables wsrep :

$ mysql -u root -e "SHOW STATUS LIKE '%wsrep%';"

Exemple de résultat :

+-----------------------------+------------------------------------------+
| Variable_name               | Value                                    |
+-----------------------------+------------------------------------------+
| wsrep_local_state_uuid      | af2a75b4-9e1c-11ed-9838-be4b133a6b15     |
| wsrep_protocol_version      | 7                                        |
| wsrep_last_committed        | 0                                        |
| wsrep_replicated            | 0                                        |
| wsrep_replicated_bytes      | 0                                        |
| wsrep_received              | 1                                        |
| wsrep_received_bytes        | 119                                      |
| wsrep_local_commits         | 0                                        |
| wsrep_local_cert_failures   | 0                                        |
| wsrep_local_replays         | 0                                        |
| wsrep_local_send_queue      | 0                                        |
| wsrep_local_send_queue_avg  | 0.000000                                 |  
| wsrep_local_recv_queue      | 0                                        |
| wsrep_local_recv_queue_avg  | 0.000000                                 | 
| wsrep_cluster_size          | 1                                        | 
+-----------------------------+------------------------------------------+

Ceci confirme que Galera est opérationnel. Notez que la taille du cluster local est de 1 pour le moment.

Maintenant, démarrez MySQL sur le second nœud pour le rejoindre au cluster :

$ systemctl start mysql
# ou 
$ systemctl start mariadb

Vérifiez qu’il a rejoint le cluster avec succès :

$ mysql -u root -e "SHOW STATUS LIKE '%wsrep%';"

Nous devrions maintenant voir la taille du cluster comme étant 2 :

| wsrep_cluster_size | 2 |

De plus, exécutez mysql -e "SHOW STATUS LIKE '%wsrep%';" sur le nœud 1 à nouveau et les variables de statut doivent être synchronisées entre les deux nœuds.

Notre cluster Galera à deux nœuds est prêt !

Test du fonctionnement du cluster

Testons que la réplication entre les deux nœuds fonctionne comme prévu.

Sur le nœud 1, créez une base de test et insérez des données :

mysql> CREATE DATABASE cluster_test;
mysql> USE cluster_test;  
mysql> CREATE TABLE test (id INT, message VARCHAR(20));
mysql> INSERT INTO test VALUES (1, 'Bonjour Galera');
mysql> SELECT * FROM test;
+------+-----------------+
| id   | message         |  
+------+-----------------+
|    1 | Bonjour Galera  |
+------+-----------------+

Maintenant, vérifiez le même contenu de table depuis le nœud 2 :

mysql> USE cluster_test;
mysql> SELECT * FROM test;
+------+-----------------+
| id   | message         |
+------+-----------------+
|    1 | Bonjour Galera  |  
+------+-----------------+

La ligne a été répliquée du nœud 1 vers le nœud 2 comme prévu.

Testons aussi la récupération d’arrêt. Arrêtez MySQL sur le nœud 1 :

$ systemctl stop mysql
# ou
$ systemctl stop mariadb

Sur le nœud 2, connectez-vous à MySQL et vérifiez que les requêtes fonctionnent toujours :

mysql> USE cluster_test; 
mysql> SELECT * FROM test;
+------+-----------------+
| id   | message         |
+------+-----------------+
|    1 | Bonjour Galera  |
+------+-----------------+

Le nœud 2 reste opérationnel malgré l’arrêt du nœud 1 puisque toutes les données sont répliquées.

Redémarrez le nœud 1 :

$ systemctl start mysql  
# ou
$ systemctl start mariadb

Il va se resynchroniser automatiquement avec le nœud 2. Exécutez SHOW STATUS LIKE '%wsrep%'; sur les deux nœuds pour confirmer que les valeurs correspondent.

Ceci démontre la haute disponibilité fournie par Galera !

Surveillance et gestion du cluster

Maintenant que nous avons un cluster Galera opérationnel, examinons quelques conseils pour le surveiller et le gérer.

Vérification du statut du cluster

Utilisez le daemon garbd pour vérifier les statistiques de haut niveau du cluster :

$ garbd -a gcomm://192.168.1.101,192.168.1.102 -g my_galera_cluster
Galera cluster Node 1/2 info:
  evs::protover => 7
  evs::uuid     => af2a75b4-9e1c-11ed-9838-be4b133a6b15
  evs::status   => Primary
  evs::state    => Synced
Galera cluster Node 2/2 info:
  evs::protover => 7
  evs::uuid     => af2a75b4-9e1c-11ed-9838-be4b133a6b15
  evs::status   => Primary
  evs::state    => Synced

Cela montre que les deux nœuds sont dans l’état Synced et font partie du même cluster.

Surveillance de l’état des nœuds

Utilisez mysqladmin pour vérifier les variables Galera sur chaque nœud :

$ mysqladmin -uroot -p -h192.168.1.101 variables | grep wsrep
| wsrep_cluster_conf_id | 25 |
| wsrep_cluster_size | 2 |
| wsrep_cluster_state_uuid | af2a75b4-9e1c-11ed-9838-be4b133a6b15 |
| wsrep_cluster_status | Primary |
$ mysqladmin -uroot -p -h192.168.1.102 variables | grep wsrep
| wsrep_cluster_conf_id | 25 |  
| wsrep_cluster_size | 2 |
| wsrep_cluster_state_uuid | af2a75b4-9e1c-11ed-9838-be4b133a6b15 |
| wsrep_cluster_status | Primary |

Des valeurs comme la taille du cluster, l’UUID, le statut doivent correspondre sur tous les nœuds.

Vérification du statut de transfert SST

Lorsqu’un nouveau nœud rejoint le cluster, le transfert d’état (SST) est utilisé pour synchroniser les données vers celui-ci.

Surveillez la progression SST avec:

$ mysql -e "SHOW STATUS LIKE 'wsrep_local_state_uuid'"  
+----------------------------------+--------------------------------------+
| Variable_name                    | Value                                |
+----------------------------------+--------------------------------------+
| wsrep_local_state_uuid           | af2a75b4-9e1c-11ed-9838-be4b133a6b15 | 
+----------------------------------+--------------------------------------+
$ mysql -e "SHOW STATUS LIKE 'wsrep_local_state_comment'"
+-----------------------------------+----------+
| Variable_name                     | Value    |
+-----------------------------------+----------+
| wsrep_local_state_comment         | Synced   |
+-----------------------------------+----------+

Pendant que le SST est en cours, wsrep_local_state_comment affichera le pourcentage de synchronisation.

Vérification du statut de récupération

Lorsqu’un nœud rejoint après une déconnexion, le statut peut être vérifié avec :

mysql>SHOW STATUS WHERE `variable_name` LIKE'wsrep_%';

Surveillez wsrep_local_state_comment pour des valeurs comme Recovering ou Donor/Desynced pendant la récupération.

Ainsi, les différentes étapes de synchronisation et récupération du cluster peuvent être suivies.

Surveillance de la taille du cluster

Pour vérifier le nombre de nœuds dans le cluster :

mysql> SHOW STATUS LIKE 'wsrep_cluster_size';
+--------------------+-------+ 
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 2     |  
+--------------------+-------+

Cela doit correspondre au nombre de nœuds attendus.

Nous pouvons aussi utiliser le script clustercheck pour surveiller la taille du cluster :

$ clustercheck
Cluster is CORRECT (2 nodes)
$

Cela avertira si des nœuds sont manquants ou en surplus.

Vérification de la cohérence des nœuds

Le statut du cluster doit être vérifié pour s’assurer que tous les nœuds contiennent les mêmes données.

La comparaison de la variable wsrep_local_state_uuid entre les nœuds indique la cohérence :

$ mysql -e "SHOW STATUS LIKE 'wsrep_local_state_uuid'\G" -h192.168.1.101
   *************************** 1. row ***************************
   Variable_name: wsrep_local_state_uuid
        Value: af2a75b4-9e1c-11ed-9838-be4b133a6b15
$ mysql -e "SHOW STATUS LIKE 'wsrep_local_state_uuid'\G" -h192.168.1.102
   *************************** 1. row ***************************
   Variable_name: wsrep_local_state_uuid
        Value: af2a75b4-9e1c-11ed-9838-be4b133a6b15

Si l’UUID correspond sur les nœuds, les données sont cohérentes.

Vérification du statut des connexions

Utilisez socat pour vérifier le statut de connexion TCP entre les nœuds :

$ socat - TCP:192.168.1.101:4567  
>
$ socat - TCP:192.168.1.102:4567
>

Cela confirme que le port TCP 4567 est ouvert entre les nœuds pour le trafic de réplication du cluster Galera.

Nous pouvons aussi utiliser MySQL pour vérifier le statut de connexion :

mysql> SHOW STATUS WHERE `variable_name` LIKE '%connection%'; 
+-----------------------------+-------+
| Variable_name               | Value |
+-----------------------------+-------+
| Slave_connections           | 0     |
| Max_used_connections        | 2     |  
| Aborted_connects            | 0     |
| Max_used_connections        | 2     |
+-----------------------------+-------+

Surveillez le nombre de connexions ouvertes pour détecter des problèmes.

Cela donne un aperçu de l’état général du cluster et de la connectivité.

Suivi de l’historique des nœuds

L’historique des nœuds peut être utile pour le dépannage ou l’analyse d’événements :

mysql> SHOW STATUS LIKE 'wsrep_local_state_uuid%';
+--------------------------------+--------------------------------------+
| Variable_name                  | Value                                |
+--------------------------------+--------------------------------------+  
| wsrep_local_state_uuid         | af2a75b4-9e1c-11ed-9838-be4b133a6b15 |
| wsrep_local_state_uuid_history | af2a75b4-9e1c-11ed-9838-be4b133a6b15 |
+--------------------------------+--------------------------------------+

Tous les anciens UUID de cluster seront ajoutés à wsrep_local_state_uuid_history lors d’événements comme des récupérations.

De même, le nombre de changements d’appartenance au cluster est suivi par :

mysql> SHOW STATUS LIKE 'wsrep_cluster_size_change%'; 
+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| wsrep_cluster_size_changes    | 1     |
| wsrep_cluster_size_change_history | 1 |  
+-------------------------------+-------+

Cela donne un aperçu de l’activité du cluster au fil du temps.

En utilisant ces variables de statut et commandes, le cluster Galera peut être surveillé pour un fonctionnement adéquat. Des problèmes comme les déconnexions de nœuds, le décalage de réplication ou la perte de cohérence peuvent être rapidement détectés et débuggés.

Configuration de l’arbitre Galera (facultative)

Pour un cluster à deux nœuds, nous devrions configurer un arbitre Galera pour éviter les scénarios de split brain. L’arbitre est un processus léger qui fournit un quorum pour que le cluster détermine quel nœud doit continuer à fonctionner en cas de partition réseau.

Sur un troisième serveur, installez seulement le paquet galera-4 ou galera.

Modifiez /etc/my.cnf avec:

[mysqld]
wsrep_provider=/usr/lib64/galera-4/libgalera_smm.so 
[galera]
wsrep_cluster_address="gcomm://192.168.1.101,192.168.1.102"
wsrep_cluster_name='my_galera_cluster'

Démarrez l’arbitre :

$ galera_arbitrator

Vérifiez les logs dans /var/log/mysql/galera.log pour vous assurer qu’il s’est connecté au cluster avec succès.

L’arbitre participera maintenant aux calculs de quorum et fournira un basculement automatique en cas de scénario de split brain. Cela évite les pertes de données en cas de partition réseau.

Conclusion

Dans ce guide détaillé, nous avons couvert les étapes d’installation, de configuration et de surveillance d’un cluster Galera à deux nœuds sur les distributions Ubuntu/Debian et CentOS/RHEL étape par étape avec des exemples pratiques.

Les points clés à retenir sont :

  • Galera permet de construire des clusters MySQL multi-maître pour la haute disponibilité.
  • La réplication en temps réel au niveau ligne assure la cohérence.
  • Les nœuds peuvent être ajoutés ou supprimés dynamiquement.
  • Rejoindre, transférer l’état et gérer le quorum des nœuds est automatique.
  • Surveiller les variables de statut clés comme les mesures wsrep.
  • L’arbitre Galera prévient les scénarios de split brain.

Un cluster Galera à deux nœuds convient bien pour réduire les temps d’arrêt et assurer la redondance pour de nombreuses applications. Des nœuds supplémentaires peuvent être introduits de manière transparente ultérieurement si nécessaire.

En utilisant ce didacticiel comme guide, vous pouvez désormais déployer des clusters MySQL hautement disponibles avec Galera sur Ubuntu/Debian et CentOS/RHEL.

Laisser un commentaire