dfbec9cdaa
Il n’est pas toujours nécessaire de repartir un nœud lorsqu’on change la configuration Galera.
144 lines
4.9 KiB
Markdown
144 lines
4.9 KiB
Markdown
---
|
||
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
|
||
|
||
|
||
## Installation
|
||
|
||
~~~
|
||
# apt install galera-3 mariadb-server rsync
|
||
~~~
|
||
|
||
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_.
|
||
|
||
## 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 :
|
||
|
||
~~~
|
||
[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
|
||
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
|
||
~~~
|
||
|
||
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_ :
|
||
|
||
~~~
|
||
# mysqld_bootstrap
|
||
~~~
|
||
|
||
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 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 et 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` 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.
|
||
|
||
Il se peut que `seqno` soit à -1. Dans ce cas-là, le nœud n’a pas été arrêté proprement. On peut alors récupérer le numéro de séquence avec la commande `mysqld --wsrep-recover`. L’information peut être récupéré dans `/var/log/mysql/error.log`
|
||
|
||
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://"`
|
||
* 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
|