From 69f84469f11f12107d1ce75a397ba2e9196ed90f Mon Sep 17 00:00:00 2001 From: Ludovic Poujol Date: Wed, 7 Dec 2022 10:41:42 +0100 Subject: [PATCH] =?UTF-8?q?WIP=20-=20Gros=20compl=C3=A9ments=20documentati?= =?UTF-8?q?on=20galera?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- HowtoMySQL/Galera.md | 88 +++++++++++++++++++++++++++++--------------- 1 file changed, 58 insertions(+), 30 deletions(-) diff --git a/HowtoMySQL/Galera.md b/HowtoMySQL/Galera.md index 6b6def37..d084f18c 100644 --- a/HowtoMySQL/Galera.md +++ b/HowtoMySQL/Galera.md @@ -3,7 +3,7 @@ categories: databases title: Réplication MySQL avec Galera ... -## Aperçu +* Documentation : Galera est un module de réplication synchrone et multi-master avec une tolérance de panne transparente. Il se base sur la _Write-Set Replication API_ @@ -17,20 +17,16 @@ supportées par la réplication et ne seront donc pas répliquées ! Il est conseillé d'avoir au minimum 3 serveurs en cas de conflit de réplication, mais 2 peuvent suffire. -Documentation officielle (MariaDB ≥ 10.1) : https://mariadb.com/kb/en/library/galera-cluster/ - -Documentation officielle (MariaDB < 10.1) : http://galeracluster.com/documentation-webpages/gettingstarted.html - ## Installation -~~~ -# apt install galera-3 mariadb-server rsync -~~~ +Depuis Debian 9 (Stretch), le MariaDB plugin de réplication Galera est présent dans le paquet MariaDB serveur. De même, le paquet galera-4 (ou galera-3 suivant la version de MariaDB) est une dépendance de mariadb-serveur. Il n'y a donc aucune action supplémentaire à faire. -Note : pour Debian jessie, il est nécessaire d'installer le paquet _mariadb-galera-server_. Depuis stretch, qui contient MariaDB 10.1, le plugin de réplication a été inclus dans le paquet de standard _mariadb-server_. +Pour revoir la partie installation de MariaDB, il y a notre [Howto MySQL](/HowtoMySQL) -## Configuration réseau +## Mise en place + +### Configuration réseau / Firewalling La réplication Galera utilise des ports réseau dédiés. Il est donc nécessaire d'autoriser les ports suivant dans les pare-feu des machines : @@ -38,7 +34,8 @@ La réplication Galera utilise des ports réseau dédiés. Il est donc nécessai - 4568/tcp - 4444/tcp -## Mise en place +### Configuration de MariaDB + Ajouter la configuration suivante dans le fichier _/etc/mysql/mariadb.conf.d/galera.cnf_, sur toutes les machines du cluster : @@ -62,17 +59,17 @@ wsrep_on=ON wsrep_provider=/usr/lib/galera/libgalera_smm.so wsrep_provider_options="gcache.size=300M; gcache.page_size=300M" -wsrep_cluster_name=" SHOW STATUS LIKE 'wsrep_%'; _wsrep_cluster_size_ indique ici le nombre de machine dans le cluster. -## Récupération d’un cluster complètement arrêté. +## Monitoring -Dans certains cas, on peut se retrouver dans une situation ou tous les nœuds du cluster sont arrêtés et il devient impossible de rejoindre le cluster, car il n’existe plus. +### Nagios -Cela nécessite de réamorcer manuellement le cluster. Commencer par inspecter le fichier `/var/lib/mysql/grastate.dat` pour identifier le nœud qui contient la version la plus avancée de la base de donnée. +Pour un monitoring simple du cluster, on peut utiliser le check nagios suivant sur chaque noeuds. + +Celui-ci surveillera : + +* Qu'il y ait assez de noeuds actifs dans le cluster +* Que le noeud surveillé soit master (ie: donc cluster opérationel) +* Que le cluster n'ait pas mis le noeud en pause trop longtemps pour qu'il récupère du retard (en surveillant `wsrep_flow_control_paused`) + +### Munin + +TODO + +## Plomberie + +### Récupération d’un cluster complètement arrêté. + +Dans certains cas, on peut se retrouver dans une situation ou tous les nœuds du cluster sont arrêtés. Lors du démarrage d'un noeud il devient impossible de rejoindre le cluster, car il n’existe plus. + +Cela nécessite de réamorcer manuellement le cluster. Commencer par inspecter le fichier `/var/lib/mysql/grastate.dat` sur chaque machines pour identifier le nœud qui contient la version la plus avancée de la base de donnée. Si tous les nœuds ont bien été arrêtés, c’est donc le nœud avec le "seqno" le plus grand qui contient la dernière version de la base. C’est lui qui doit servir de point de départ. @@ -136,8 +147,25 @@ Il se peut que `seqno` soit à -1. Dans ce cas-là, le nœud n’a pas été arr Voici les étapes pour réamorcer manuellement à partir du nœud le plus à jour: -* Modifier `/etc/mysql/mariadb.conf.d/galera.cnf` pour définir `wsrep_cluster_address="gcomm://"` +* Modifier `/etc/mysql/mariadb.conf.d/galera.cnf` pour définir `wsrep_cluster_address="gcomm://"` et ainsi le forcer à démarrer seul * Démarrer mariadb : `systemctl start mariadb` * Rétablir la configuration du cluster dans `/etc/mysql/mariadb.conf.d/galera.cnf` (Un redémarrage n’est pas nécessaire) Après le démarrage correct du premier nœud, on peut démarrer un à un les autres nœuds du cluster + +### Récupération d'un noeud avec un datadir corrompu + +Dans une situation de corruption de données sur un noeud (causée par exemple par une saturation disque), on peut alors détruire le datadir pour le forcer à se resynchroniser de zéro. +Simplement créer le dossier avec les bon droits suiffit. Galera s'occupera du reste. + +**Remarque importante** : Attention, il est préférable d'avoir deux noeuds "sains". En effet, le noeud corrompu va récupérer l'état du cluster via un des noeuds sains avec un rsync des données. Mais pendant l'opération, le noeud sain source du rsync, va passer en état "DONOR", et donc ne pas accepter de faire des écritures. +S'il n'y a qu'un seul noeud sain, l'opération va donc causer une interruption de service. + +~~~ +# mv /var/lib/mysql /var/lib/mysql.delete_me +# mkdir /var/lib/mysql +# chmod 700 /var/lib/mysql +# chown mysql: /var/lib/mysql +# systemctl start mariadb +~~~ +