Pour assurer la haute disponibilité de vos bases de données, il existe plusieurs solutions dont Galera.
Galera Cluster pour MySQL est un véritable cluster multi-maître basé sur la réplication synchrone.
Il s’agit d’une solution de haute disponibilité facile à utiliser, qui offre un temps de fonctionnement élevé du système, aucune perte de données et une évolutivité pour une croissance future.
Le clustering améliore la disponibilité de votre base de données en répartissant la charge sur différents serveurs. Si un serveur tombe en panne, d’autres sont rapidement disponibles pour continuer à servir les données.
MariaDB Galera est une solution de clustering multimaître qui vous permet de lire et d’écrire sur n’importe quel nœud du cluster.
Avec MariaDB Galera, une modification apportée à un nœud est répliquée sur tous les nœuds. MariaDB Galera prend en charge les moteurs de stockage XtraDB / InnoDB et n’est disponible que sous Linux.
Ce tutoriel vous guide pour installer un cluster MySQL avec Galera sur Debian 10.

Table des matières
Introduction
Le cluster MariaDB et Galera fonctionne avec un serveur maître, on y a adjoint des noeuds qui se synchronisent entre eux.
Lorsque ce dernier passe hors ligne, un nouveau serveur MySQL est désigné comme maître afin de continuer à servir les données.
Cela permet de répondre aux exigences suivantes :
- Topologie multi-maître actif-actif
- Jointure automatique des nœuds
- Capacité de lecture et d’écriture sur n’importe quel nœud de cluster
- Contrôle automatique de l’appartenance, les nœuds en échec sont supprimés du cluster
- Provisionnement automatique des nœuds
- Pas de décalage de l’esclave
- Aucune transaction perdue
- Moins de latences client
Je vous conseille de lire la documentation suivante pour choisir votre architecture Galera correctement.
En effet, le nombre de noeud est important pour éviter les conditions split-brain.
C’est à dire, lorsque des noeuds s’isolent et ne sont plus mis à jour.
Pour activer les basculements automatiques, vous devez utiliser au moins trois nœuds. Gardez à l’esprit que cela s’étend à d’autres niveaux d’infrastructure, pour les mêmes raisons.
- Les clusters à commutateur unique doivent utiliser au moins 3 nœuds.
- Les clusters couvrant des commutateurs doivent utiliser au moins 3 commutateurs.
- Ceux couvrant des réseaux doivent utiliser au moins 3 réseaux.
- Enfin ceux couvrant les centres de données doivent utiliser au moins 3 centres de données.
En outre, il est possible de définir des poids sur les noeuds pour favoriser un serveur à passer en primaire, lorsque le précédente tombe.
La documentation : Quorum Components
Installer le cluster MySQL MariaDB Galera sur Debian 10
Installer MariaDB
Installer MariaDB de manière classique avec apt sur chaque serveur Debian :
apt-get install mariadb-server
Ensuite, il faut augmenter la limite de fichiers ouverts sur Debian, sinon vous pouvez rencontrer l’erreur suivante au démarrage de MySQL :
Mar 22 08:22:46 ns3178554 mysqld[8165]: 2021-03-22 8:22:46 0 [Note] /usr/sbin/mysqld (mysqld 10.3.27-MariaDB-0+deb10u1) starting as process 8165 ...
Mar 22 08:22:46 ns3178554 mysqld[8165]: 2021-03-22 8:22:46 0 [Warning] Could not increase number of max_open_files to more than 16384 (request: 32214)
Pour cela, éditez le fichier /etc/systemd/system/mysql.service :
vim /etc/systemd/system/mysql.service
Puis cherchez la ligne LimitNOFile et passez le à infinity :
LimitNOFILE=infinity
Enfin relancez le service daemon :
systemctl daemon-reload
Si vous utilisez iptables comme pare-feu, il faut autoriser les ports pour que les noeuds MySQL puissent communiquer entre eux.
Adaptez les variables suivantes :
- mysql_ip permet d’indiquer les adresses IP des noeuds MySQL
- local : l’interface réseau utilisée pour les connexions réseaux
mysql_ip="54.38.xxx 51.91.xxx 51.210.xxx"
for ip in echo $mysql_ip
do
iptables -A INPUT -i $local -m state --state NEW,ESTABLISHED,RELATED -s $ip -p tcp -m multiport --dport 4567,4568,4444,3306 -j ACCEPT
iptables -A OUTPUT -o $local -m state --state ESTABLISHED,RELATED -d $ip -p tcp -m multiport --sport 4567,4568,4444,3306 -j ACCEPT
iptables -A INPUT -i $local -m state --state ESTABLISHED,RELATED -s $ip -p tcp -m multiport --sport 4567,4568,4444,3306 -j ACCEPT
iptables -A OUTPUT -o $local -m state --state NEW,ESTABLISHED,RELATED -d $ip -p tcp -m multiport --dports 4567,4568,4444,3306 -j ACCEPT
done
Configurer et démarrer le serveur primaire Galera
Arrêtez le service MySQL :
/etc/init.d/mysql stop
Créez le fichier /etc/mysql/mariadb.conf.d/99-galera.cnf avec le contenu suivant.
[galera]
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_address=gcomm://51.210.xxx,51.91.xxx,54.38.xxx
binlog_format=row
default_storage_engine=InnoDB
# innodb
innodb_autoinc_lock_mode=2
innodb_buffer_pool_size=128M
#options
bind-address=0.0.0.0
wsrep_cluster_name=cluster
wsrep_node_name=master
wsrep_node_address=51.xxx
wsrep_sst_method=rsync
Adaptez les variables et paramètres de la section [galera] suivants :
- wsrep_provider — le chemin de la librairie galera
- wsrep_cluster_address — avec les adresses IP des noeuds du cluster MariaDB
- binlog_format=row — le format des fichiers de logs MySQL, obligatoirement en row pour un cluster MariaDB galera
- default_storage_engine=InnoDB — On force le moteur de table InnoDB, seul compatible avec XtraDB pour la réplication dans le cluster
Puis on trouve des variables wsrep optionnels sauf pour wsrep_node_address :
- wsrep_cluster_name= — le nom du cluster
- wsrep_node_name=master — le nom du noeud, ici on choisit master comme il s’agit du maître
- wsrep_node_address= — l’adresse IP du noeud
- wsrep_sst_method — La méthode de réplication quand un nouveau noeud est ajouté
Ici on créé donc un cluster nommé cluster avec comme maître master.
Démarrez le cluster avec la commande galera suivante :
galera_new_cluster
Cela doit aussi démarrer MySQL qui écoutent sur les ports 3306 et 4567 :
- 3306 est le port par défaut pour les connexions client MySQL et State Snapshot Transfer utilisant mysqldump pour les sauvegardes.
- 4567 est réservé au trafic de réplication de cluster Galera. La réplication multicast utilise à la fois le transport TCP et UDP sur ce port.
- 4568 est le port pour le transfert d’état incrémentiel.
- 4444 est utilisé pour tous les autres transferts de snapshots d’état.
Configurer les noeuds esclaves
Installez le serveur MariaDB sur chaque noeud :
apt-get install mariadb-server
Puis créez le fichier /etc/mysql/mariadb.conf.d/99-galera.cnf en adaptant ce con tenu :
[galera]
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_address=gcomm://51.210.xxx,51.91.xxx,54.38.xxx
binlog_format=row
default_storage_engine=InnoDB
# innodb
innodb_autoinc_lock_mode=2
innodb_buffer_pool_size=128M
#options
wsrep_cluster_name=cluster
wsrep_node_name=n2
wsrep_node_address=54.38.xxx
wsrep_sst_method=rsync
Ainsi les paramètres sont globalement identiques à ceux du maître. Simplement les paramètres wsrep_node et wsrep_node_address diffèrent.
Ici donc, c’est le noeud qui a pour nom n2 dans le cluster nommé cluster.
Relancez MySQL :
/etc/init.d/mysql restart
Répétez l’opération sur les autres serveurs en modifiant les deux paramètres.
Lorsque le noeud rejoint le serveur primaire, dans /var/log/mysql/error.log, on obtient les notifications suivantes :
2021-03-24 9:09:25 0 [Note] WSREP: Member 2.0 (n2) requested state transfer from '*any*'. Selected 1.0 (n1)(SYNCED) as donor.
2021-03-24 9:09:26 0 [Note] WSREP: (6f2c10dc, 'tcp://0.0.0.0:4567') turning message relay requesting off
2021-03-24 9:09:26 0 [Note] WSREP: 1.0 (n1): State transfer to 2.0 (n2) complete.
2021-03-24 9:09:26 0 [Note] WSREP: Member 1.0 (n1) synced with group.
2021-03-24 9:09:39 0 [Note] WSREP: 2.0 (n2): State transfer from 1.0 (n1) complete.
2021-03-24 9:09:39 0 [Note] WSREP: Member 2.0 (n2) synced with group.
Vérifier le fonctionnement du cluster MySQL MariaDB Galera
Pour vérifier le bon fonctionnement du cluster, il faut analyser les variables wsrep_.
Pour lister celle-ci :
mysql -u root -p -e "show status like 'wsrep_%'";
- wsrep_cluster_size — indiquer le nombre de noeuds connectés. C’est la variable la plus importante pour s’assurer que vous avez bien tous les noeuds connectés.
- wsrep_local_state_comment — l’état du cluster. Lorsqu’il est en fonctionne, il doit être sur synced. A vérifier sur chaque noeud
- wsrep_local_send_queue_avg — La longueur moyenne de la file d’attente depuis la dernière commande FLUSH STATUS. Les valeurs considérablement supérieures à 0,0 indiquent une limitation de la réplication ou un problème de débit réseau.
- wsrep_local_send_queue_max — La longueur maximale de la file d’attente
Reportez-vous à la documentation : Galera Status Variables
Pour afficher que le nombre de noeuds connectés :
show status like 'wsrep_cluster_size';
Enfin on peut créer une table dans la base de données test pour vérifier qu’elle se réplique bien.
USE test;
CREATE TABLE `test` (
`i` int(11) default NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
Connectez-vous sur tous les noms et vérifiez le contenu de la base test qui doit contenir une table test :
mysql -u root -p
use test;
show tables;
Ajouter un nouveau nœud MySQL à un cluster de réplication Galera
Par la suite, il est tout à fait possible d’ajouter de nouveaux noeuds à votre cluster MySQL Galera.
Pour cela, suivez ce tutoriel :
Liens
Le cluster MySQL permet d’assurer la haute disponibilité d’une application ou d’un serveur WEB.
On en parle dans cet article :