wiki/HowtoMySQL/Galera.md

144 lines
4.9 KiB
Markdown
Raw Normal View History

2018-05-10 17:25:46 +02:00
---
categories: databases
title: Réplication MySQL avec Galera
...
## Aperçu
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_
(_wsrep API_) de MySQL.
La réplication est totalement transparente pour l'application, aucun potentiel
délai de réplication ou gestion des locks entre les serveurs n'est à prévoir.
Cependant les tables non-transactionnelles de type MyISAM ne sont pas
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
2018-05-10 17:25:46 +02:00
## Installation
~~~
# apt install galera-3 mariadb-server rsync
2018-05-10 17:25:46 +02:00
~~~
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_.
2018-05-10 17:25:46 +02:00
## Configuration réseau
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 :
- 4567/tcp, 4567/udp
- 4568/tcp
- 4444/tcp
## Mise en place
Ajouter la configuration suivante dans le fichier _/etc/mysql/mariadb.conf.d/galera.cnf_, sur toutes les machines du cluster :
2018-05-10 17:25:46 +02:00
~~~
[mysqld]
# The following MySQL options are mandatory for Galera to work
bind-address=0.0.0.0
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
innodb_flush_log_at_trx_commit=0
innodb_buffer_pool_size=<votre innodb_buffer_pool_size actuel + ~ 5% pour Galera>
binlog_format=ROW
# Galera cluster configuration
wsrep_on=ON
2018-05-10 17:25:46 +02:00
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_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_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.
Bien s'assurer que le fichier est lisible par MariaDB :
~~~
# chmod 644 /etc/mysql/mariadb.conf.d/galera.cnf
~~~
2018-05-10 17:25:46 +02:00
Ensuite 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 MySQL est éteint sur chaque serveur :
~~~
# /etc/init.d/mysql stop
~~~
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 :
~~~
# galera_new_cluster
~~~
Pour les versions précédentes, on peut utiliser le script _/usr/bin/mysqld_bootstrap_ :
2018-05-10 17:25:46 +02:00
~~~
# mysqld_bootstrap
2018-05-10 17:25:46 +02:00
~~~
Sur les autres serveurs, simplement démarrer MySQL de manière habituelle :
~~~
# /etc/init.d/mysql start
~~~
## Administration
Vérifier l'état du cluster :
~~~
mysql> SHOW STATUS LIKE 'wsrep_%';
+---------------------------+------------+
| Variable_name | Value |
+---------------------------+------------+
...
| wsrep_local_state_comment | Synced (6) |
| wsrep_cluster_size | 3 |
| wsrep_ready | ON |
+---------------------------+------------+
~~~
_wsrep_cluster_size_ indique ici le nombre de machine dans le cluster.
## Récupération dun 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 et il devient impossible de rejoindre le cluster, car il nexiste plus.
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.
Si tous les nœuds ont bien été arrêtés, cest donc le nœud avec le "seqno" le plus grand qui contient la dernière version de la base. Cest lui qui doit servir de point de départ.
Il se peut que `seqno` soit à -1. Dans ce cas-là, le nœud na pas été arrêté proprement. On peut alors récupérer le numéro de séquence avec la commande `mysqld --wsrep-recover`. Linformation peut être récupéré dans `/var/log/mysql/error.log`
2019-03-25 20:48:26 +01:00
Voici les étapes pour réamorcer manuellement à partir du nœud le plus à jour:
2019-03-25 16:56:51 +01:00
* Modifier `/etc/mysql/mariadb.conf.d/galera.cnf` pour définir `wsrep_cluster_address="gcomm://"`
* Démarrer mariadb : `systemctl start mariadb`
* Rétablir la configuration du cluster dans `/etc/mysql/mariadb.conf.d/galera.cnf` (Un redémarrage nest pas nécessaire)
2019-03-25 20:48:26 +01:00
Après le démarrage correct du premier nœud, on peut démarrer un à un les autres nœuds du cluster