Comment configurer la réplication synchrone multi-maître de MariaDB Galera avec Debian 10

MariaDB propose deux solutions différentes de haute disponibilité (HA) et de mise en grappe. La première est la réplication maître/esclave standard de MariaDB qui peut être configurée dans différentes topologies, principalement à des fins d’équilibrage de charge, d’HA et de sauvegarde. La seconde est MariaDB Galera, une solution de clustering synchrone multi-maître. Ses principales caractéristiques sont les suivantes :

  • Multi-maître : Tous les nœuds d’un cluster Galera peuvent effectuer des opérations de lecture et d’écriture, offrant ainsi une meilleure évolutivité.
  • Les nœuds peuvent rejoindre un cluster automatiquement, et sont expulsés en cas de défaillance.
  • La réplication Galera est synchrone, ce qui signifie que les changements sur un nœud sont garantis d’être appliqués sur les autres nœuds. En théorie, cela garantit qu’aucune donnée n’est perdue lorsqu’un nœud tombe en panne.

Ce guide te guidera dans l’installation de MariaDB et sa configuration dans un cluster Galera. Nous utiliserons trois nœuds Debian 10 pour la démonstration, bien que n’importe quel nombre (≥3) de nœuds puisse être utilisé. La configuration de deux nœuds dans un cluster Galera est techniquement possible mais n’offre pas de tolérance de panne car un nœud défaillant entraînera l’arrêt de l’autre nœud.

Configuration requise

  • Trois instances Debian 10 ou plus.
  • Accès à l’utilisateur root ou à tout utilisateur ayant les privilèges sudo.
  • La variable d’environnement $EDITOR doit être définie.

REMARQUE : Les grappes Galera peuvent fonctionner sur un réseau WAN ou LAN. Si tes nœuds partagent un réseau privé, utilise des adresses IP privées le cas échéant. Sinon, il faut utiliser des adresses WAN.

Si tu utilises un utilisateur sudo, ouvre et utilise un shell root pendant toute la durée de cette installation :

sudo -s

Étape 1 : Installer MariaDB

Cette étape doit être exécutée sur tous les nœuds.

Utilise les commandes suivantes pour installer MariaDB, la bibliothèque Galera et Rsync. Ce dernier est utilisé par Galera.

apt update
apt install -y mariadb-server mariadb-client galera-3 rsync

Assure-toi que le service MariaDB est activé :

systemctl enable mariadb.service

Sécurise tes instances MariaDB à l’aide du script mysql_secure_installation:

mysql_secure_installation

Réponds aux questions comme indiqué ci-dessous et assure-toi de choisir un mot de passe fort pour l’utilisateur root de MySQL.

Enter current password for root (enter for none): Press <Enter>
Set root password? [Y/n] y
New password: your_password
Re-enter new password: your_password
Remove anonymous users? [Y/n] y
Disallow root login remotely? [Y/n] y
Remove test database and access to it? [Y/n] y
Reload privilege tables now? [Y/n] y
All done!  If you've completed all of the above steps, your MariaDB
installation should now be secure.

Étape 2 : Configurer MariaDB

Cette étape doit être exécutée sur tous les nœuds.

Arrête le service MariaDB sur tous les nœuds :

systemctl stop mariadb.service

Par défaut, le démon MariaDB écoute les connexions sur localhost uniquement. Pour que le cluster fonctionne, cela doit être changé en une adresse accessible de l’extérieur. Pour ce faire, modifie le fichier d’options /etc/mysql/mariadb.conf.d/50-server.cnf:

$EDITOR /etc/mysql/mariadb.conf.d/50-server.cnf

Trouve la ligne suivante :

bind-address = 127.0.0.1

Si tu utilises un réseau privé pour le cluster et que tu ne veux pas exposer MariaDB à d’autres réseaux (c’est-à-dire le WAN), indique l’adresse IPv4 locale pour chaque nœud. Sinon, utilise 0.0.0.0 qui indique à MariaDB d’écouter sur toutes les interfaces. Par exemple :

bind-address = 0.0.0.0

Enregistre la modification et quitte ton éditeur de texte.

Nous allons maintenant configurer les options liées au cluster. Crée un nouveau fichier d’options :

$EDITOR /etc/mysql/mariadb.conf.d/99-cluster.cnf

Saisis la configuration sensible suivante dans le fichier, en remplaçant les adresses IP. Elle doit être identique sur tous les nœuds.

[galera]

wsrep_on = on wsrep_provider = /lib/galera/libgalera_smm.so wsrep_cluster_address = gcomm://192.0.2.1,192.0.2.2,192.0.2.3 wsrep_cluster_name = galera_cluster_0 default_storage_engine = InnoDB innodb_autoinc_lock_mode = 2 innodb_doublewrite = 1 binlog_format = ROW
  • wsrep_on = on active la réplication des jeux d’écriture, la fonctionnalité sous-jacente utilisée par Galera.
  • wsrep_provider indique le chemin d’accès à la bibliothèque galera. Elle est fournie par le paquet galera-3 à /lib/galera/libgalera_smm.so sur Debian 10.
  • wsrep_cluster_address doit contenir au moins une adresse d’un autre membre de la grappe. Il est recommandé de répertorier tous les membres de la grappe. Aucun ordre particulier n’est nécessaire.
  • wsrep_cluster_name doit être unique pour le cluster et doit être identique sur tous les nœuds du même cluster Galera.
  • Les autres options sont nécessaires pour que Galera fonctionne correctement et ne doivent pas être modifiées.

Étape 3 : Démarre le cluster

Assure-toi que MariaDB est arrêtée/inactive sur tous les nœuds avant de poursuivre :

systemctl status mariadb.service

Pour démarrer le cluster, un nœud doit d’abord le créer. Sur Debian 10, cela peut être fait avec le script galera_new_cluster. Le script ne doit être exécuté que sur un seul nœud, et une seule fois pour initialiser la grappe.

galera_new_cluster

Cela lancera MariaDB sur le nœud actuel. Assure-toi qu’il fonctionne avec :

systemctl status mariadb.service

Puis démarre MariaDB sur les autres nœuds avec :

systemctl start mariadb.service

Le cluster devrait maintenant être opérationnel.

Étape 4 : Test

Pour t’assurer que le cluster fonctionne comme prévu, choisis n’importe quel nœud et connecte-toi à MariaDB :

mysql -u root -p

Envoie l’instruction suivante pour créer une base de données :

> CREATE DATABASE test0;
> \q

Vérifie ensuite la présence de cette nouvelle base de données sur tous les autres nœuds:

mysql -u root -p -e "SHOW DATABASES;"

La commande ci-dessus devrait renvoyer une liste contenant test0:

+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| test0              |
+--------------------+

Tu voudras peut-être faire un test plus approfondi en écrivant dans le cluster depuis chaque nœud. Une fois que tu es satisfait des tests, nettoie toutes les bases de données inutiles du cluster. N’importe quel nœud peut être utilisé.

mysql -u root -p -e "DROP DATABASE test0;"

Étape 5 : Conseils de dépannage

Utilise la requête suivante pour afficher des informations sur l’état actuel du nœud/cluster :

mysql -u root -p -e "SELECT * FROM information_schema.global_status WHERE variable_name IN ('WSREP_CLUSTER_STATUS','WSREP_LOCAL_STATE_COMMENT','WSREP_CLUSTER_SIZE','WSREP_EVS_REPL_LATENCY','WSREP_EVS_DELAYED','WSREP_READY');"

Un cluster de 3 nœuds en bonne santé devrait renvoyer ce qui suit :

+---------------------------+----------------+
| VARIABLE_NAME             | VARIABLE_VALUE |
+---------------------------+----------------+
| WSREP_CLUSTER_SIZE        | 3              |
| WSREP_CLUSTER_STATUS      | Primary        |
| WSREP_EVS_DELAYED         |                |
| WSREP_EVS_REPL_LATENCY    | 0/0/0/0/0      |
| WSREP_LOCAL_STATE_COMMENT | Synced         |
| WSREP_READY               | ON             |
+---------------------------+----------------+
  • WSREP_CLUSTER_SIZE représente le nombre actuel de nœuds dans le composant du cluster.
  • WSREP_CLUSTER_STATUS représente l’état du composant du cluster et non du cluster dans son ensemble.
  • WSREP_EVS_DELAYED indique une liste de nœuds qui sont retardés. Une valeur vide est attendue pour les clusters sains.
  • WSREP_EVS_REPL_LATENCY affiche la latence de réplication au format min/avg/max/stddev/samplesize. Les valeurs sont affichées en secondes. Des latences très élevées peuvent entraîner une dégradation des performances.
  • WSREP_LOCAL_STATE_COMMENT indique l’état actuel du nœud.
  • WSREP_READY indique si le nœud peut accepter des requêtes.

Lorsqu’un nœud d’un cluster à 3 nœuds perd sa connectivité, le cluster est divisé en un composant primaire composé de 2 nœuds et un composant non primaire. Le composant primaire n’est pas affecté par la panne et continue à fonctionner normalement. Du point de vue du composant non-primaire, la requête présentée ci-dessus renverrait ce qui suit :

+---------------------------+--------------------------------------------------------------------------------------------------------------------------------+
| VARIABLE_NAME             | VARIABLE_VALUE                                                                                                                 |
+---------------------------+--------------------------------------------------------------------------------------------------------------------------------+
| WSREP_CLUSTER_SIZE        | 1                                                                                                                              |
| WSREP_CLUSTER_STATUS      | non-Primary                                                                                                                    |
| WSREP_EVS_DELAYED         | 6b7864f2-fe7d-11e9-84ab-93e58c0d2907:tcp://192.0.2.1:4567:3,a421be89-fe7d-11e9-a91e-7e62f7562e58:tcp://192.0.2.3:4567:2        |
| WSREP_EVS_REPL_LATENCY    | 0/0/0/0/0                                                                                                                      |
| WSREP_LOCAL_STATE_COMMENT | Initialized                                                                                                                    |
| WSREP_READY               | OFF                                                                                                                            |
+---------------------------+--------------------------------------------------------------------------------------------------------------------------------+

Remarque la valeur WSREP_EVS_DELAYED, qui indique des problèmes de connectivité avec les autres nœuds.

Sur les nœuds du composant primaire, la même requête renvoie :

+---------------------------+----------------------------------------------------------------+
| VARIABLE_NAME             | VARIABLE_VALUE                                                 |
+---------------------------+----------------------------------------------------------------+
| WSREP_CLUSTER_SIZE        | 2                                                              |
| WSREP_CLUSTER_STATUS      | Primary                                                        |
| WSREP_EVS_DELAYED         | a2217526-fe7d-11e9-8692-1f2f0cdb403d:tcp://192.0.2.2:4567:2    |
| WSREP_EVS_REPL_LATENCY    | 0/0/0/0/0                                                      |
| WSREP_LOCAL_STATE_COMMENT | Synced                                                         |
| WSREP_READY               | ON                                                             |
+---------------------------+----------------------------------------------------------------+

Pour récupérer des pannes de nœuds uniques, aucune intervention manuelle n’est nécessaire. Lorsque le nœud défaillant se reconnecte au cluster, il se synchronise automatiquement avec le cluster.

Plus d’informations

Pour les options de configuration avancées, reporte-toi à Variables système de Galera Cluster.

Vous aimerez aussi...