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

De Wiki doc

Aucun résumé des modifications
(Correction d'orthographe)
 
(4 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">Suite a plusieurs tests, cette solution n'est pas adaptée pour faire du cluster via VPN.</span>''' Cette outils ne fonctionne que dans un réseau interne. Nous somme partie sur une solution de réplication MySQL Master-Master.
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.


'''<span style="color:#FF0000">Tous les manipulations sont à faire sur tous les serveur (sauf contraction).</span>'''
À 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.


=Ajout des dépôts MariaDB=
=Installation=
Sur Debian 8 "Jessie", les paquets de Galera ne sont pas dans les dépôts de Debian contrairement à Debian 9 "Stretch".
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 la clef du dépôt de MariaDB:
==Nœud 1 et 2==
  # apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xcbcb082a1bb943db
Installation des paquets
  apt update
apt -y install --no-install-recommends mariadb-server mariadb-client


*Ajouter dans le fichier '''/etc/apt/sources.list''' :
Sécuriser l'installation par défaut
<span style="color:#808080">[...]</span>
  mysql_secure_installation
  deb [arch=amd64,i386] http://ftp.igh.cnrs.fr/pub/mariadb/repo/10.1/debian jessie main


*Faire un update:
=Configuration=
  # apt update
==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


=Installer MariaDB et Galera=
La configuration de la grappe ''Galera'' se fait par le fichier suivant :
*Installer MariaDB et Galera:
  vim /etc/mysql/mariadb.conf.d/50-server.cnf
  # apt install -y rsync mariadb-client mariadb-galera-server galera


=Configurer le cluster=
À la fin du fichier, ajouter une section avec les lignes suivantes :
*Créer le fichier '''/etc/mysql/conf.d/galera.cnf''' sur tous les serveurs et ajouter:


[mysqld]
<source lang="bash">
#mysql settings
[galera]
binlog_format=ROW
wsrep_on=ON
default-storage-engine=innodb
wsrep_provider=/usr/lib/galera/libgalera_smm.so
innodb_autoinc_lock_mode=2
wsrep_cluster_address=gcomm://galera1,galera2
innodb_doublewrite=1
binlog_format=row
query_cache_size=0
default_storage_engine=InnoDB
query_cache_type=0
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0
bind-address=0.0.0.0
wsrep_cluster_name="galera_cluster"
#galera settings
wsrep_node_address="galera1"
wsrep_on=ON
</source>
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 />
==Nœud 2==
Modifier '''test_cluster''' par le nom du cluster de votre choix.
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


*Stopper MariaDB sur tous les machines du cluster:
De la même manière, la configuration de la grappe ''Galera'' se fait par le fichier suivant :
  # service mysql stop
  vim /etc/mysql/mariadb.conf.d/50-server.cnf


*<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:
À la fin du fichier, ajouter une section avec les lignes suivantes :
# galera_new_cluster


*Toujours sur <span style="color:#FF0000">''cluster01''</span>, exécuter la commende suivant:
<source lang="bash">
# mysql -u root -p -e 'SELECT VARIABLE_VALUE as "cluster size" FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME="wsrep_cluster_size"'
[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"
</source>


Résultat:
=Démarrage=
+--------------+
Le démarrage doit être fait sur le nœud 1 et ensuite sur les autres nœuds.
| cluster size |
+--------------+
| 1           |
+--------------+


Le '''1''' correspond au nombre de serveur connecté au cluster.
==Nœud 1==
Il faut démarrer ''MariaDB'' en mode "initialisation" :
galera_new_cluster


*<span style="color:#FF0000">'''Sur les autres serveurs du cluster'''</span>, il suffit de démarrer MariaDB:
''Note: Cette commande lance le service <source lang="bash" inline>mariadb.service</source>.''
# service mysql start


*Sur <span style="color:#FF0000">''cluster01''</span>, si vous exécutez:
{{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.}}
# mysql -u root -p -e 'SELECT VARIABLE_VALUE as "cluster size" FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME="wsrep_cluster_size"'


Résultat:
==Nœud 2==
+--------------+
| cluster size |
+--------------+
| 2           |
+--------------+


Vous voyez le chiffre augmenté suivant le nombre de serveur connecté dans le cluster.
{{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''.
 
{| 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=
=Sources=
* Dépôt de MariaDB : https://downloads.mariadb.org/mariadb/repositories/#mirror=cnrs&version=10.1&distro_release=jessie--jessie&distro=Debian
* https://computingforgeeks.com/how-to-setup-mariadb-galera-cluster-on-debian/
* Utilisation de Galera : https://blog.sprinternet.at/2016/03/mariadb-10-1-galera-cluster-on-debian-8-jessie/
* https://mariadb.com/kb/en/getting-started-with-mariadb-galera-cluster/
* Pour la configuration de Galera : http://galeracluster.com/documentation-webpages/configuration.html
* 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 à 00: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

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