WIP - Gros compléments documentation galera
This commit is contained in:
parent
ae91f1d2e9
commit
69f84469f1
|
|
@ -3,7 +3,7 @@ categories: databases
|
|||
title: Réplication MySQL avec Galera
|
||||
...
|
||||
|
||||
## Aperçu
|
||||
* Documentation : <https://mariadb.com/kb/en/galera-cluster/>
|
||||
|
||||
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="<nom arbitraire du cluster"
|
||||
wsrep_cluster_name="<nom arbitraire du cluster>"
|
||||
wsrep_cluster_address="gcomm://<liste des adresses IP des machines du cluster, séparées par des virgules>"
|
||||
|
||||
wsrep_sst_method=rsync
|
||||
|
||||
wsrep_node_address="<adresse IP de la machine>"
|
||||
wsrep_node_address="<adresse IP de la machine - Communication inter-noeuds>"
|
||||
wsrep_node_name="<nom de la machine>"
|
||||
wsrep_retry_autocommit=4
|
||||
~~~
|
||||
|
||||
*Note :* seul _wsrep_node_address_ et _wsrep_node_name_ sont différents d'une machine à l'autre.
|
||||
*Note Importante :* seul _wsrep_node_address_ et _wsrep_node_name_ sont différents d'une machine à l'autre.
|
||||
|
||||
Bien s'assurer que le fichier est lisible par MariaDB :
|
||||
|
||||
|
|
@ -80,30 +77,26 @@ Bien s'assurer que le fichier est lisible par MariaDB :
|
|||
# chmod 644 /etc/mysql/mariadb.conf.d/galera.cnf
|
||||
~~~
|
||||
|
||||
Ensuite pour initialiser le nouveau cluster, il est nécessaire de démarrer l'une des machines avec l'option `--wsrep-new-cluster`.
|
||||
### Amorce d'un cluster
|
||||
|
||||
Avant tout, s'assurer que MySQL est éteint sur chaque serveur :
|
||||
Pour initialiser le nouveau cluster, il est nécessaire de démarrer l'une des machines avec l'option `--wsrep-new-cluster`.
|
||||
|
||||
Avant tout, s'assurer que MariaDB est éteint sur chaque serveur :
|
||||
|
||||
~~~
|
||||
# /etc/init.d/mysql stop
|
||||
# systemctl stop mariadb.service
|
||||
~~~
|
||||
|
||||
MariaDB 10.1 (Debian stretch) vient avec le script _galera_new_cluster_, il est préférable de l'utiliser pour la première initialisation. À faire sur un des serveurs uniquement :
|
||||
Depuis MariaDB 10.1 (Debian stretch), il y a le script _galera_new_cluster_ qui s'occupe de l'amorce du cluster. il est préférable de l'utiliser pour la première initialisation. Cette invocation soit être réalisée sur **un seul serveur**
|
||||
|
||||
~~~
|
||||
# galera_new_cluster
|
||||
~~~
|
||||
|
||||
Pour les versions précédentes, on peut utiliser le script _/usr/bin/mysqld_bootstrap_ :
|
||||
Dès que la commande est terminée, on peut démarrer les autres noeuds MariaDB de manière normale
|
||||
|
||||
~~~
|
||||
# mysqld_bootstrap
|
||||
~~~
|
||||
|
||||
Sur les autres serveurs, simplement démarrer MySQL de manière habituelle :
|
||||
|
||||
~~~
|
||||
# /etc/init.d/mysql start
|
||||
# systemctl start mariadb.service
|
||||
~~~
|
||||
|
||||
## Administration
|
||||
|
|
@ -124,11 +117,29 @@ mysql> 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 <https://github.com/fridim/nagios-plugin-check_galera_cluster> 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
|
||||
~~~
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue