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

De Wiki doc

m (Ycharbi a déplacé la page MariaDB - Cluster de serveurs (Galera) vers MariaDB - Grappe de serveurs avec Galera sans laisser de redirection : Francisation du titre)
(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.)
Ligne 1 : Ligne 1 :
[[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 mais fonctionne tout de même selon le modèle maître-esclave pour l'organisation de la grappe.


'''<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. De plus, le maître d'une grappe peut être changé sans conséquences sur son ensemble lors d'une défaillance (ceci se fait en fonction de la machine ayant les données les plus à jour).


=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_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 machine est maître ou ''non-Primary'' si elle est esclave
|-
| <source lang="sql" inline>show status like 'wsrep_cluster_state_uuid';</source> || UUID de l'état de la grappe
|}
 
=Cas de coupure=
De part la nature de la relation de réplication entre nos nœuds, les serveurs doivent êtres arrêtés selon une certaine méthode. Si l'un des nœuds arrête son service ''MariaDB'' proprement (via <source lang="bash" inline>systemctl stop mariadb.service</source>), le serveur restant poursuit sont fonctionnement normalement en passant maître (état ''Primary''). À l'inverse, si un des nœud se trouve hors service de façon brutale, le nœud restant passe automatiquement en lecture seule en attendant le retour du deuxième.
 
==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. En terme technique (car rien est magique), lors de l'arrêt du nœud, un nouveau membre devient maître (état ''Primary'') de la grappe.
 
Lors de l'allumage du service ''MariaDB'' sur le nœud précédemment éteint, une synchronisation est exécuté entre le maître (qui est à 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==
=== Le processus est arrêté violemment ===
Dans ce cas, ''Systemd'' s'occupe de le relancer automatiquement. Pendant cette micro coupure, le deuxième nœud est en lecture seul.
 
=== La machine est arrêté violemment ===
Dans ce cas, le deuxième nœud est en lecture seule et attend le retour de son pair.
 
{{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
 
Le nœud ayant la valeur <source lang="bash" inline>safe_to_bootstrap: 1</source> doit initialiser la grappe (sera considéré comme ''Primary'') :
galera_new_cluster
 
{{astuce|Si aucun nœud ne possède cette valeur, vous devez décider quelle base de données est la plus récente, puis passer cette valeur 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>.}}
 
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==
 
{{attention|Nous n'avons pas encore testé ce cas. Ceci n'est que simple supposition.}}
 
Ce cas est similaire à 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://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/

Version du 6 novembre 2020 à 21:22

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 mais fonctionne tout de même selon le modèle maître-esclave pour l'organisation de la grappe.

À 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. De plus, le maître d'une grappe peut être changé sans conséquences sur son ensemble lors d'une défaillance (ceci se fait en fonction de la machine ayant les données les plus à jour).

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_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 machine est maître ou non-Primary si elle est esclave
show status like 'wsrep_cluster_state_uuid'; UUID de l'état de la grappe

Cas de coupure

De part la nature de la relation de réplication entre nos nœuds, les serveurs doivent êtres arrêtés selon une certaine méthode. Si l'un des nœuds arrête son service MariaDB proprement (via systemctl stop mariadb.service), le serveur restant poursuit sont fonctionnement normalement en passant maître (état Primary). À l'inverse, si un des nœud se trouve hors service de façon brutale, le nœud restant passe automatiquement en lecture seule en attendant le retour du deuxième.

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. En terme technique (car rien est magique), lors de l'arrêt du nœud, un nouveau membre devient maître (état Primary) de la grappe.

Lors de l'allumage du service MariaDB sur le nœud précédemment éteint, une synchronisation est exécuté entre le maître (qui est à 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

Le processus est arrêté violemment

Dans ce cas, Systemd s'occupe de le relancer automatiquement. Pendant cette micro coupure, le deuxième nœud est en lecture seul.

La machine est arrêté violemment

Dans ce cas, le deuxième nœud est en lecture seule et attend le retour de son pair.

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

Le nœud ayant la valeur safe_to_bootstrap: 1 doit initialiser la grappe (sera considéré comme Primary) : 

galera_new_cluster

ASTUCE

Si aucun nœud ne possède cette valeur, vous devez décider quelle base de données est la plus récente, puis passer cette valeur manuellement à 1 ou via la commande sed -ie '/safe_to/c\safe_to_bootstarp: 1' /var/lib/mysql/grastate.dat.

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

ATTENTION

Nous n'avons pas encore testé ce cas. Ceci n'est que simple supposition.

Ce cas est similaire à 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.ycharbi.fr/index.php?title=MariaDB_-_Grappe_de_serveurs_avec_Galera&oldid=1196 »