Base de données
Installation et Configuration MariaDB avec Galera Cluster
Architecture du Cluster
Schéma de l'infrastructure
Voici le schéma de notre structure qui permettra de faire de la haute disponibilité et de la synchronisation bidirectionnelle :
DB1 → MariaDB + Galera DB2 → MariaDB + Galera ARB → Galera Arbitrator
Cette architecture garantit la continuité de service même en cas de défaillance d'un serveur de base de données.
1 — Installation MariaDB et Galera
Installation du dépôt officiel MariaDB
Sur les deux serveurs db1 et db2, il faut impérativement installer le dépôt officiel MariaDB afin d'obtenir les versions les plus récentes et compatibles avec Galera.
Exécuter la commande suivante sur db1 et db2 :
curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | bash
Cette commande télécharge et configure automatiquement le dépôt MariaDB officiel.
Installation des packages MariaDB et Galera
Une fois le dépôt configuré, vous pouvez installer MariaDB et Galera sans problème.
Installation des composants nécessaires sur les deux serveurs :
dnf install -y MariaDB-server MariaDB-client MariaDB-backup galera-4
Cette commande installe le serveur MariaDB, le client, l'outil de sauvegarde et le module Galera 4.
2 — Configuration du Cluster Galera
Arrêt du service MariaDB
Sur db1 (la première machine), arrêter le service MariaDB avant la configuration du cluster :
systemctl stop mariadb
Cette étape est nécessaire pour configurer Galera sans conflit.
Configuration Galera sur db1
Nous allons configurer Galera qui se trouve dans le fichier /etc/my.cnf.d/galera.cnf.
Éditer le fichier de configuration :
vi /etc/my.cnf.d/galera.cnf
Dans db1, insérer la configuration suivante :
[galera] wsrep_on=ON wsrep_provider=/usr/lib64/galera-4/libgalera_smm.so wsrep_cluster_name="galera_cluster" wsrep_cluster_address="gcomm://IP_DB1,IP_DB2" wsrep_node_name="db1" wsrep_node_address="IP_DB1" wsrep_sst_method=rsync binlog_format=ROW default_storage_engine=InnoDB innodb_autoinc_lock_mode=2
Cette configuration active wsrep (Write Set Replication), définit l'adresse du cluster et configure le nœud db1.
Configuration Galera sur db2
Sur le second serveur db2, éditer le même fichier de configuration :
vi /etc/my.cnf.d/galera.cnf
Dans db2, insérer la configuration suivante :
[galera] wsrep_on=ON wsrep_provider=/usr/lib64/galera-4/libgalera_smm.so wsrep_cluster_name="galera_cluster" wsrep_cluster_address="gcomm://IP_DB1,IP_DB2" wsrep_node_name="db2" wsrep_node_address="IP_DB2" wsrep_sst_method=rsync binlog_format=ROW default_storage_engine=InnoDB innodb_autoinc_lock_mode=2
La configuration est identique à db1, seuls les paramètres wsrep_node_name et wsrep_node_address changent pour identifier le second nœud.
3 — Configuration du Pare-feu
Ouverture des ports Galera
Il ne faut pas oublier d'ouvrir tous les ports suivants pour que les services puissent communiquer entre eux correctement.
Pour les deux serveurs db1 et db2, éditer le fichier iptables :
vi /etc/sysconfig/iptables
Puis insérer les règles suivantes au milieu du fichier :
-A INPUT -p tcp --dport 3306 -j ACCEPT -A INPUT -p tcp --dport 4567 -j ACCEPT -A INPUT -p udp --dport 4567 -j ACCEPT -A INPUT -p tcp --dport 4568 -j ACCEPT -A INPUT -p tcp --dport 4444 -j ACCEPT
Explication des ports :
- 3306 : Port MySQL/MariaDB standard pour les connexions clients
- 4567 : Port de réplication Galera (TCP et UDP)
- 4568 : Port IST (Incremental State Transfer)
- 4444 : Port SST (State Snapshot Transfer)
Application des règles
Ne pas oublier de recharger et démarrer iptables pour appliquer les modifications :
systemctl reload iptables systemctl start iptables
Vérifier que les règles ont bien été ajoutées :
iptables -nvL | grep -E "3306|4567|4568|4444"
4 — Initialisation du Cluster
Activation du service MariaDB
Sur les deux serveurs db1 et db2, activer le service MariaDB au démarrage :
systemctl enable mariadb
Cette commande créé un lien symbolique pour le démarrage automatique du service.
Création du cluster sur db1
Sur db1 (le nœud principal), initialiser le nouveau cluster Galera :
galera_new_cluster
Cette commande crée le cluster pour la synchronisation et la haute disponibilité. Le premier nœud devient le point de référence initial du cluster.
Démarrage de db2
Uniquement sur db2 (le second nœud), démarrer le service MariaDB :
systemctl start mariadb
Le serveur db2 va automatiquement rejoindre le cluster existant et se synchroniser avec db1.
Vérification du cluster
Vérifier que la création du cluster a bien fonctionné en affichant la taille du cluster :
mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size';"
Résultat attendu dans la console :
+--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | wsrep_cluster_size | 2 | +--------------------+-------+
Vous devriez voir 2 en résultat, confirmant que les deux nœuds sont bien connectés au cluster.
5 — Installation de l'Arbitre Galera
Principe de l'arbitre
L'arbitre Galera (garbd) est un composant léger qui participe au vote du cluster sans stocker de données. Il permet de maintenir le quorum en cas de panne d'un nœud et d'éviter les situations de split-brain.
Installation du dépôt MariaDB
Sur une nouvelle machine dédiée à l'arbitre, installer le dépôt MariaDB :
curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | bash
Installation de Galera Arbitrator
Installer le package galera-4 qui contient tout le nécessaire pour l'arbitre :
dnf install galera-4
Vérification de l'installation
Vérifier que l'installation s'est bien déroulée en affichant la version :
garbd --version
Résultat attendu dans la console :
Galera Arbitrator (garbd) 26.x.x
Vous devriez voir quelque chose comme Galera Arbitrator (garbd) 26.x.x.
Démarrage de l'arbitre
Exécuter ce bloc de commande directement dans le terminal pour démarrer l'arbitre :
garbd \ --group=galera_cluster \ --address="gcomm://192.168.40.250,192.168.40.252" \ --option="gmcast.listen_addr=tcp://0.0.0.0:4567"
Explication des paramètres :
- --group : Nom du cluster Galera (doit correspondre à wsrep_cluster_name)
- --address : Adresses IP des nœuds du cluster
- --option : Port d'écoute de l'arbitre
6 — Tests et Vérification
Vérification de l'état du cluster
Vérifier que l'arbitre a bien rejoint le cluster en affichant la taille totale :
mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size';"
Résultat attendu dans la console :
+--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | wsrep_cluster_size | 3 | +--------------------+-------+
Vous devriez maintenant voir 3 (db1 + db2 + arbitre).
Test de la réplication multi-maître
Sur db1, créer une base de données de test :
mysql -u root -p -e "CREATE DATABASE test_replication;" mysql -u root -p -e "USE test_replication; CREATE TABLE users (id INT PRIMARY KEY, name VARCHAR(50));" mysql -u root -p -e "USE test_replication; INSERT INTO users VALUES (1, 'JanMerie'), (2, 'Leanan');"
Sur db2, vérifier que les données ont été répliquées automatiquement :
mysql -u root -p -e "USE test_replication; SELECT * FROM users;"
Résultat attendu dans la console :
+----+---------+ | id | name | +----+---------+ | 1 | JanMerie| | 2 | Leanan | +----+---------+
Test de la réplication bidirectionnelle
Sur db2, insérer de nouvelles données :
mysql -u root -p -e "USE test_replication; INSERT INTO users VALUES (3, 'Gorfon');"
Sur db1, vérifier que les données ajoutées sur db2 sont bien présentes :
mysql -u root -p -e "USE test_replication; SELECT * FROM users;"
Résultat attendu dans la console :
+----+-----------+ | id | name | +----+-----------+ | 1 | JanMerie | | 2 | Leanan | | 3 | Gorfon | +----+-----------+