« MariaDB - Grappe de serveurs avec Galera » : différence entre les versions

De Wiki doc

(Page créée avec « Category:linux Category:base_de_données '''<span style="color:#FF0000">Tous les manipulations sont à faire sur tous les serveur (sauf contraction).</span>''' =A... »)
 
(Correction d'orthographe)
 
(9 versions intermédiaires par 2 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
[[Category:linux]]
[[Category:base_de_données]]
[[Category:base_de_données]]
'''<span style="color:#FF0000">Tous les manipulations sont à faire sur tous les serveur (sauf contraction).</span>'''
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 [[MariaDB - Réplication master-master|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.


=Ajout des dépôts MariaDB=
À 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.
Sur Debian 8 "Jessie", les paquets de Galera ne sont pas dans les dépôts de Debian contrairement à Debian 9 "Stretch".


*Ajouter la clef du dépôt de MariaDB:
=Installation=
$ apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xcbcb082a1bb943db
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 <source lang="bash" inline>mariadb-galera-server</source> et <source lang="bash" inline>galera</source> non présent dans les dépôts ''Debian''.


*Ajouter dans le fichier '''/etc/apt/sources.list''' :
==Nœud 1 et 2==
  <span style="color:#808080">[...]</span>
Installation des paquets
  deb [arch=amd64,i386] http://ftp.igh.cnrs.fr/pub/mariadb/repo/10.1/debian jessie main
  apt update
  apt -y install --no-install-recommends mariadb-server mariadb-client


*Faire un update:
Sécuriser l'installation par défaut
  $ apt update
  mysql_secure_installation


=Installer MariaDB et Galera=
=Configuration=
*Installer MariaDB et Galera:
==Nœud 1==
  $ apt install -y rsync mariadb-client mariadb-galera-server galera
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


=Configurer le cluster=
La configuration de la grappe ''Galera'' se fait par le fichier suivant :
*Créer le fichier '''/etc/mysql/conf.d/galera.cnf''' sur tous les serveurs et ajouter:
vim /etc/mysql/mariadb.conf.d/50-server.cnf


[mysqld]
À la fin du fichier, ajouter une section avec les lignes suivantes :
#mysql settings
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
innodb_doublewrite=1
query_cache_size=0
query_cache_type=0
bind-address=0.0.0.0
#galera settings
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_name="<span style="color:#FF0000">test_cluster</span>"
wsrep_cluster_address=gcomm://<span style="color:#FF0000">cluster01,cluster02,cluster03</span>
wsrep_sst_method=rsync


Modifier '''cluster01,cluster02,cluster03''' par les IP de tous vos serveurs en cluster. ex: '''gcomm://10.0.99.31,10.0.99.32,10.0.99.33'''.<br />
<source lang="bash">
Modifier '''test_cluster''' par le nom du cluster de votre choix.
[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"
</source>


*Stopper MariaDB sur tous les machines du cluster:
==Nœud 2==
  $ service mysql stop
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


*<span style="color:#FF0000">'''Sur l'un des serveur du cluster'''</span> que l'on va appeler <span style="color:#FF0000">''cluster01''</span> dans ce tuto, exécuter:
De la même manière, la configuration de la grappe ''Galera'' se fait par le fichier suivant :
  $ galera_new_cluster
  vim /etc/mysql/mariadb.conf.d/50-server.cnf


*Toujours sur <span style="color:#FF0000">''cluster01''</span>, exécuter la commende suivant:
À la fin du fichier, ajouter une section avec les lignes suivantes :
$ mysql -u root -p -e 'SELECT VARIABLE_VALUE as "cluster size" FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME="wsrep_cluster_size"'


Résultat:
<source lang="bash">
+--------------+
[galera]
| cluster size |
wsrep_on=ON
+--------------+
wsrep_provider=/usr/lib/galera/libgalera_smm.so
| 1            |
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"
</source>


Le '''1''' correspond au nombre de serveur connecté au cluster.
=Démarrage=
Le démarrage doit être fait sur le nœud 1 et ensuite sur les autres nœuds.


*<span style="color:#FF0000">'''Sur les autres serveurs du cluster'''</span>, il suffit de démarrer MariaDB:
==Nœud 1==
  $ service mysql start
Il faut démarrer ''MariaDB'' en mode "initialisation" :
  galera_new_cluster


*Sur <span style="color:#FF0000">''cluster01''</span>, si vous exécutez:
''Note: Cette commande lance le service <source lang="bash" inline>mariadb.service</source>.''
$ mysql -u root -p -e 'SELECT VARIABLE_VALUE as "cluster size" FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME="wsrep_cluster_size"'


Résultat:
{{info|La commande <source lang="bash" inline>galera_new_cluster</source> permet à priori de démarrer le nœud avec le paramètre <source lang="bash" inline>wsrep_cluster_address=gcomm://</source>. En d'autre terme, il s'exécute seul afin de s'éviter la recherche d'informations sur un autre nœud.}}
+--------------+
| cluster size |
+--------------+
| 2            |
+--------------+


Vous voyez le chiffre augmenté suivant le nombre de serveur connecté dans le cluster.
==Nœud 2==


=Liens=
{{attention|Les commandes suivantes sont à réaliser seulement si le nœud 1 est démarré.}}
* Dépôt de MariaDB : https://downloads.mariadb.org/mariadb/repositories/#mirror=cnrs&version=10.1&distro_release=jessie--jessie&distro=Debian
 
* Utilisation de Galera : https://blog.sprinternet.at/2016/03/mariadb-10-1-galera-cluster-on-debian-8-jessie/
{{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é).}}
* Pour la configuration de Galera : http://galeracluster.com/documentation-webpages/configuration.html
 
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''.
 
{| class="wikitable"
|-
! Argument !! Signification
|-
| <source lang="sql" inline>SHOW STATUS LIKE 'wsrep%';</source> || Toutes les informations. Renvoie un tableau regroupant l’ensemble des informations de la grappe
|-
| <source lang="sql" inline>show status like 'wsrep_cluster_size';</source> || Taille de notre grappe. Renvoie le nombre de machines faisant partie de la grappe
|-
| <source lang="sql" inline>show status like 'wsrep_incoming_addresses';</source> || Adresse des participants. Renvoie l'adresse IP et le port des machines faisant partie de la grappe
|-
| <source lang="sql" inline>show status like 'wsrep_local_state_comment';</source> || État de synchronisation de notre nœud. Renvoie ''Synced'' si tout est bon ou ''Initialized'' si le pair est injoignable
|-
| <source lang="sql" inline>show status like 'wsrep_cluster_status';</source> || 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)
|-
| <source lang="sql" inline>show status like 'wsrep_cluster_state_uuid';</source> || 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 <source lang="bash" inline>journalctl -f</source>.}}
 
==Un des nœuds est arrêté violemment==
 
{{info|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 <source lang="bash" inline>seqno</source> 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 <source lang="bash" inline>safe_to_bootstrap: 1</source> 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 <source lang="bash" inline>sed -ie '/safe_to/c\safe_to_bootstarp: 1' /var/lib/mysql/grastate.dat</source> 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 <source lang="bash" inline>mariadb.service</source> 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 <source lang="bash" inline>journalctl -f</source>.}}
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 <source lang="bash" inline>mysqld</source>
* Suivre la section [[#Tous%20les%20n%C5%93uds%20sont%20arr%C3%AAt%C3%A9s%20proprement|Tous les nœuds sont arrêtés proprement]]. La différence est probablement le fait qu'aucun nœud n'aura la valeur <source lang="bash" inline>safe_to_bootstrap: 1</source>. Dans ce cas, appliquer l'astuce y étant décrite.
 
=Sources=
* https://computingforgeeks.com/how-to-setup-mariadb-galera-cluster-on-debian/
* https://mariadb.com/kb/en/getting-started-with-mariadb-galera-cluster/
* https://mariadb.com/kb/en/galera-cluster-status-variables/#wsrep_cluster_status
* https://www.symmcom.com/docs/how-tos/databases/how-to-recover-mariadb-galera-cluster-after-partial-or-full-crash
* https://easyteam.fr/galera-cluster-mariadb-principes-installation/
* https://www.debyum.com/restart-galera-cluster-after-reboot-bootstrap-node/

Dernière version du 27 février 2022 à 01:33

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