« MariaDB - Grappe de serveurs avec Galera » : différence entre les versions
(Refonte complète de la documentation après tests (beaucoup trop de choses on changées depuis la dernière version). Considérer cette modification comme une nouvelle page.) |
(Correction des cas de coupure + reformulation de certains textes + correction du concept de "Primary" et "non-Primary" + ajout d'une commande d'affichage d'état global + ajout d'une source.) |
||
| Ligne 1 : | Ligne 1 : | ||
[[Category:base_de_données]] | [[Category:base_de_données]] | ||
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 | 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. | ||
À 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 | À 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= | =Installation= | ||
| Ligne 93 : | Ligne 93 : | ||
|- | |- | ||
! Argument !! Signification | ! Argument !! Signification | ||
|- | |||
| <source lang="sql" inline>SHOW STATUS LIKE 'wsrep%';</source> || Toutes les informations. Renvoie un tableau rgrouppant l'enssemble 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_cluster_size';</source> || Taille de notre grappe. Renvoie le nombre de machines faisant partie de la grappe | ||
| Ligne 100 : | Ligne 102 : | ||
| <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_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 | | <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 superieur à la moitier du nombre total de machines de la grappe (lecture seul) et ''Disconnected'' qui le nœud n'appartient à aucune grappe (état par defaut) | ||
|- | |- | ||
| <source lang="sql" inline>show status like 'wsrep_cluster_state_uuid';</source> || UUID de l'état de la grappe | | <source lang="sql" inline>show status like 'wsrep_cluster_state_uuid';</source> || UUID de l'état de la grappe | ||
| Ligne 106 : | Ligne 108 : | ||
=Cas de coupure= | =Cas de coupure= | ||
La grappe MariaDB fonctionne comme toute grappe applicative : | |||
* Si le nombre de nœud hors service est inferieur a la moitier du nombre total de machines de la grappe alors les nœud restant fonctionne normalement | |||
* Si le nombre de nœud hors service est superieur a la moitier du nombre total de machines de la grappe alors les noœ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== | ==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 | 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 | 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>.}} | {{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== | ==Un des nœuds est arrêté violemment== | ||
{{info|Dans le cas d'un plantage du programme, ''Systemd'' s'occupe de le relancer automatiquement.}} | |||
Dans | |||
Tant que le nombre total de mahines en service de la grappe est supérieur à la moitier des noœuds déclarés dans celle-ci, il ne se passe rien de particulier. | |||
Si l'arrêt brutal vient à concerner simultanemment un nombre de nœuds supérieur à la moiteir 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.}} | {{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.}} | ||
| Ligne 131 : | Ligne 138 : | ||
cat /var/lib/mysql/grastate.dat | cat /var/lib/mysql/grastate.dat | ||
Le nœud ayant la valeur <source lang="bash" inline>safe_to_bootstrap: 1</source> doit initialiser la grappe | {{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 | galera_new_cluster | ||
{{astuce|Si aucun nœud ne possède cette valeur, | {{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. | 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. | ||
| Ligne 143 : | Ligne 152 : | ||
==Tous les nœud sont arrêtés violemment== | ==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 vercteur 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= | ||
* https://computingforgeeks.com/how-to-setup-mariadb-galera-cluster-on-debian/ | * 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/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://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://easyteam.fr/galera-cluster-mariadb-principes-installation/ | ||
* https://www.debyum.com/restart-galera-cluster-after-reboot-bootstrap-node/ | * https://www.debyum.com/restart-galera-cluster-after-reboot-bootstrap-node/ | ||
Version du 8 novembre 2020 à 16:41
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 commandegalera_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 rgrouppant l'enssemble 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 superieur à la moitier du nombre total de machines de la grappe (lecture seul) et Disconnected qui le nœud n'appartient à aucune grappe (état par defaut) |
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 inferieur a la moitier du nombre total de machines de la grappe alors les nœud restant fonctionne normalement
- Si le nombre de nœud hors service est superieur a la moitier du nombre total de machines de la grappe alors les noœ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 unjournalctl -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 mahines en service de la grappe est supérieur à la moitier des noœuds déclarés dans celle-ci, il ne se passe rien de particulier.
Si l'arrêt brutal vient à concerner simultanemment un nombre de nœuds supérieur à la moiteir 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 valeurseqno 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 commandesed -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 unjournalctl -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 vercteur 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
- 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/
