MariaDB - Grappe de serveurs avec Galera

De Wiki doc

La mise en œuvre d'une grappe de bases de données MariaDB peut se mettre en place de différentes manières. Ainsi, il est possible de réaliser une réplication maître-maître (hérité de MySQL) ou bien de passer par la méthode intégrée à l'outil : Galera. Cette méthode propose une meilleur intégration à l'outil tout en étant simple à configurer. Elle répond au même besoin fonctionnel que la première technique.

À titre d'exemple, la synchronisation entre le site https://doc.ycharbi.fr et https://doc.lesmorin.fr se faisait traditionnellement par une réplication maître-maître MySQL. Nous nous sommes aperçus à maintes reprises qu'en l'espace de quelques mois et sans raisons apparentes, la synchronisation entre nos deux serveurs se cassait et nécessitait une intervention manuelle pour régler le problème. Avec Galera, ceci n'est théoriquement pas possible.

Installation

Une grappe Galera est réalisable à partir de deux machines (ce que nous allons expliquer ici). La configuration doit être cohérente de part et d'autre du dispositif. il est à noter que Galera est intégré à MariaDB (depuis la version 10.1). Cela n'a pas toujours été le cas. Il fallait alors installer les paquets mariadb-galera-server et galera non présent dans les dépôts Debian.

Nœud 1 et 2

Installation des paquets 

apt update
apt -y install --no-install-recommends mariadb-server mariadb-client

Sécuriser l'installation par défaut 

mysql_secure_installation

Configuration

Nœud 1

Premièrement, nous allons utiliser des noms en lieu et place des adresses IP pour joindre nos machines afin d'être libre dans d’hypothétiques modifications de ces dernières par la suite. 

echo "galera1" > /etc/hostname
echo -e "10.10.9.1\tgalera1\n10.10.9.2\tgalera2" >> /etc/hosts

La configuration de la grappe Galera se fait par le fichier suivant : 

vim /etc/mysql/mariadb.conf.d/50-server.cnf

À la fin du fichier, ajouter une section avec les lignes suivantes : 

[galera]
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_address=gcomm://galera1,galera2
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0
wsrep_cluster_name="galera_cluster"
wsrep_node_address="galera1"

Nœud 2

Ne pas oublier d'appliquer la même correspondance nom/adresse que sur le nœud 1. 

echo "galera1" > /etc/hostname
echo -e "10.10.9.1\tgalera1\n10.10.9.2\tgalera2" >> /etc/hosts

De la même manière, la configuration de la grappe Galera se fait par le fichier suivant : 

vim /etc/mysql/mariadb.conf.d/50-server.cnf

À la fin du fichier, ajouter une section avec les lignes suivantes : 

[galera]
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_address=gcomm://galera1,galera2
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0
wsrep_cluster_name="galera_cluster"
wsrep_node_address="galera2"

Démarrage

Le démarrage doit être fait sur le nœud 1 et ensuite sur les autres nœuds.

Nœud 1

Il faut démarrer MariaDB en mode "initialisation" : 

galera_new_cluster

Note: Cette commande lance le service mariadb.service.

INFORMATION

La commande galera_new_cluster permet à priori de démarrer le nœud avec le paramètre wsrep_cluster_address=gcomm://. En d'autre terme, il s'exécute seul afin de s'éviter la recherche d'informations sur un autre nœud.

Nœud 2

ATTENTION

Les commandes suivantes sont à réaliser seulement si le nœud 1 est démarré.

ASTUCE

La commande que l'on va utiliser va bloquer le prompt. Cela peut être lent si nous sommes sur un réseau à faible débit (type ADSL). Pour voir l'avancement du démarrage, il faut lancer une deuxième session (Tmux peut être utilisé).

Nous allons maintenant démarrer le service MariaDB (la commande risque de prendre du temps !) : 

systemctl restart mariadb.service

En parallèle, dans une seconde fenêtre, taper la commande suivante pour connaître l'état d'avancement: 

journalctl -f

Il est ainsi possible d’apercevoir des entrées comportant le mot clé rsync (l'outil utilisé en arrière plan pour la réplication), ce qui est bon signe !

Vérification d'état

Il est possible d'afficher l'état d'un nœud de la grappe via des commandes SQL. Connaître ces informations peut s'avérer utile en cas de défaillance et permet de mieux appréhender le système. Il s'agit de requêtes SQL à entrer dans le prompt de MariaDB.

Argument Signification
SHOW STATUS LIKE 'wsrep%'; Toutes les informations. Renvoie un tableau regroupant l’ensemble des informations de la grappe
show status like 'wsrep_cluster_size'; Taille de notre grappe. Renvoie le nombre de machines faisant partie de la grappe
show status like 'wsrep_incoming_addresses'; Adresse des participants. Renvoie l'adresse IP et le port des machines faisant partie de la grappe
show status like 'wsrep_local_state_comment'; État de synchronisation de notre nœud. Renvoie Synced si tout est bon ou Initialized si le pair est injoignable
show status like 'wsrep_cluster_status'; Rang du nœud. Renvoie Primary si la grappe est fonctionnelle, non-Primary si le nombre de nœud hors service est supérieur à la moitié du nombre total de machines de la grappe (lecture seul) et Disconnected qui le nœud n'appartient à aucune grappe (état par défaut)
show status like 'wsrep_cluster_state_uuid'; UUID de l'état de la grappe

Cas de coupure

La grappe MariaDB fonctionne comme toute grappe applicative :

  • Si le nombre de nœud hors service est inférieur a la moitié du nombre total de machines de la grappe alors les nœud restant fonctionne normalement
  • Si le nombre de nœud hors service est supérieur a la moitié du nombre total de machines de la grappe alors les nœuds restant passe en lecteur seul

C'est pour cela qu'il est plus agréable d'avoir au minimum 3 nœud dans la grappe.

Un des nœuds est arrêté proprement

Dans ce cas, lors de l'arrêt du nœud, celui-ci notifie les autres participants de son arrêt. Ceux-ci fonctionnent alors normalement sans se soucier de la perte d'un des membres.

Lors de l'allumage du service MariaDB sur le nœud précédemment éteint, une synchronisation est exécuté entre la machine la plus à jour et le nœud fraîchement démarré.

ATTENTION

Cette commande peux prendre du temps suivant les modifications effectuées. Vous pouvez contrôler l'état d'avancement avec un journalctl -f.

Un des nœuds est arrêté violemment

INFORMATION

Dans le cas d'un plantage du programme, Systemd s'occupe de le relancer automatiquement.

Tant que le nombre total de machines en service de la grappe est supérieur à la moitié des nœuds déclarés dans celle-ci, il ne se passe rien de particulier.

Si l'arrêt brutal vient à concerner simultanément un nombre de nœuds supérieur à la moitié décrite, les nœuds restant passent en lecture seule le temps de la remise en service des machines tombées.

ATTENTION

Si cette dernière ne revient jamais, il faudra casser la grappe et la refaire. Il est également possible de faire fonctionner MariaDB en dehors de la grappe en passant la valeur wsrep_on=ON à OFF du fichier de configuration.

Tous les nœuds sont arrêtés proprement

ATTENTION

Ce cas est à éviter le plus possible !

Pour remettre la grappe en marche, il faut aller sur chaque nœud et afficher l'état de la grappe de cette manière : 

cat /var/lib/mysql/grastate.dat

ASTUCE

La valeur seqno donne un numéro de séquence correspondant au niveau de synchronisation entre les nœuds. La valeur la plus élevé correspond au nœud le plus à jour.

Le nœud ayant la valeur safe_to_bootstrap: 1 doit initialiser la grappe : 

galera_new_cluster

ASTUCE

Si aucun nœud ne possède cette valeur, il faut la définir manuellement à 1 ou via la commande sed -ie '/safe_to/c\safe_to_bootstarp: 1' /var/lib/mysql/grastate.dat sur le nœud le plus à jour afin de servir d'étalon aux autres (seule un nœud dont la valeur est a "1" peut exécuter la commande ci-dessus).

Si tout se passe bien, le service mariadb.service est actif sur ce nœud. Dans ce cas, il est possible de le démarrer sur les autres nœuds.

ATTENTION

Cette commande peux prendre du temps suivant les modifications effectuées. Vous pouvez contrôler l'état d'avancement avec un journalctl -f.
systemctl restart mariadb.service

Tous les nœud sont arrêtés violemment

MariaDB communique les informations de réplication en multicast sur le port 4567. Lorsque plusieurs nœuds sont démarrés, ils communiques par ce vecteur pour s'accorder et remonter la grappe automatiquement.

Si toutefois la grappe n'est pas remonté automatiquement par MariaDB :

  • Tuer les processus exécutés par mysqld
  • Suivre la section Tous les nœuds sont arrêtés proprement. La différence est probablement le fait qu'aucun nœud n'aura la valeur safe_to_bootstrap: 1. Dans ce cas, appliquer l'astuce y étant décrite.

Sources

Récupérée de « https://doc.lesmorin.fr/index.php?title=MariaDB_-_Grappe_de_serveurs_avec_Galera&oldid=1297 »