Cet article présente les principes de base de Galera Cluster, réplication master/master, et un exemple d’installation sur centOS 7 avec mariaDB 10.2.
 

Principes de la réplication master/master

Sous Mysql, la haute-disponibilité est généralement assurée par une réplication asynchrone de type master / slave.
Les écritures ne peuvent être adressées que sur le nœud primaire, les lectures pouvant s’effectuer sur les db slaves pour alléger la charge du nœud primaire, mais cela demande une adaptation de l’application ou de son architecture.
 

En cas de panne du nœud primaire, le mécanisme de haute disponibilité consiste en une bascule vers un des nœuds slaves, promu nouveau nœud master. Le temps d’interruption peut être de quelques minutes, suivant le mécanisme et temps de détection de la panne, le load-balancing utilisé en amont.
 
Galera Cluster est une surcouche aux moteurs SGBD MySQL, permettant d’activer une réplication master-master entre les bases de données.
C’est un produit de la société CoderShip, délivré sous licence openSource GPL v2.
La réplication est synchrone entre les nœuds constituant le cluster Galera :

L’ensemble des nœuds du cluster peut être adressé en lecture-écriture, sans aucune modification de l’application.
 

Les avantages de la réplication Synchrone

Elle garantit la disponibilité de service de 24/7 :

• Aucune perte de données en cas de crash d’un nœud.
• Les réplicats de données restent cohérents.
• Aucun failover consommateur de temps.

L’architecture avec réplication synchrone vous permet d’exécuter des transactions sur tous les nœuds du cluster.
Elle garantit également la causalité à travers le groupe entier. Par exemple, un SELECT effectué après une transaction voit toujours les effets de la transaction, même si les 2 commandes SQL sont exécutées sur des nœuds différents.
Le produit amène également les fonctionnalités / avantages :

• Un vrai multi-master, l’écriture peut se faire sur chaque nœud à chaque instant
• du multi-threading au niveau réplication
• une transparence vis à vis des applications (pas de nœuds en lecture seule)
• Ajout de nœud automatiquement provisionné (State transfer), sans besoin de backup/restore de données sur le nouveau serveur.

 

Les inconvénients de la réplication Synchrone

Les protocoles de réplication assurent la coordination des opérations SQL unitairement, soit avec un two phases commit, soit avec un verrouillage distribué.
En cas  de conflits de données (mise à jour des mêmes données sur deux nœuds, au même instant), une erreur de deadlock est produite.
L’ augmentation du nombre de nœuds amène à une croissance exponentielle des temps de réponse des transactions et dans la probabilité de conflit de données.
Pour éviter des problématiques de split brain, il est conseillé de constituer son cluster avec un nombre impairs de nœuds.
 
Galera Cluster ne fonctionne actuellement qu’avec un storage engine InnoDB.
 
 

Installation d’un cluster Galera

 
Depuis la version 10.1 de mariaDB, les packages Galera ont été intégrés dans la distribution mariaDB, aucun besoin d’installation supplémentaire.
Voici un exemple de mise en œuvre simplifiée de mariaDB avec configuration de Galera Cluster sur 3 nœuds, système centOS 7.
 

Configuration système

Mes 3 VM sous VirtualBox se nomment mariadb01, mariadb02 et mariadb03,
la configuration est similaire sur ces 3 VMs :

[root@mariadb01 ~]# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.56.121 mariadb01
192.168.56.122 mariadb02
192.168.56.123 mariadb03

Le système centOS 7 est en 64 bits, dernière version disponible au moment de mon test :

[root@mariadb01 ~]# uname -a
Linux mariadb01 3.10.0-693.11.6.el7.x86_64 #1 SMP Thu Jan 4 01:06:37 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

 
Nous allons configurer le repository yum pour MySQL en utilisant le générateur automatique fournit par mariaDB.
Url de l’outil : https://mariadb.com/kb/en/library/yum/
Générer le fichier de conf en fct de la version système :

Et copier le fichier généré dans votre répertoire yum
vi /etc/yum.repos.d/MariaDB.repo

# MariaDB 10.2 CentOS repository list - created 2018-02-23 08:26 UTC
# http://downloads.mariadb.org/mariadb/repositories/
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.2/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

 
Installation des packages mariaDB

sudo yum install MariaDB-server MariaDB-client

 
Vérification des packages

[root@mariadb01 yum.repos.d]# rpm -qa | grep -i mariadb
MariaDB-compat-10.2.13-1.el7.centos.x86_64
MariaDB-common-10.2.13-1.el7.centos.x86_64
MariaDB-client-10.2.13-1.el7.centos.x86_64
MariaDB-server-10.2.13-1.el7.centos.x86_64

 
Désactivation des huge pages

[root@mariadb01 yum.repos.d]# cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
cat /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]

 
 
Désactiver le Firewall (systemctl stop firewalld)
ou autoriser les ports 4567, 4568 et 4444 pour Galera :

firewall-cmd --zone=public --add-service=mysql --permanent
firewall-cmd --zone=public --add-port=3306/tcp --permanent
firewall-cmd --zone=public --add-port=4567/tcp --permanent
firewall-cmd --zone=public --add-port=4568/tcp --permanent
firewall-cmd --zone=public --add-port=4444/tcp --permanent
# en cas de replication multicast
firewall-cmd --zone=public --add-port=4567/udp --permanent
firewall-cmd --reload

 
# selinux disabled

cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of three two values:
# targeted - Targeted processes are protected,
# minimum - Modification of targeted policy. Only selected processes are protected.
# mls - Multi Level Security protection.
SELINUXTYPE=targeted

 
 

Configuration mariaDB

 
Pour chaque noeuds du cluster, j’utilise les répertoires par défaut proposés lors de l’install des rpm mariaDB
# securisation de mysql et arret des serveurs (sous user linux root)

sudo mysql_secure_installation
systemctl stop mysqld

Et création d’un user dba, avec les droits admin sur le serveur mysql.
 
Le répertoire des librairies Galera est : /usr/lib64/galera/libgalera_smm.so
Configuration par défaut maria DB : /etc/my.cnf

#
# include all files from the config directory
#
!includedir /etc/my.cnf.d

 
Nous allons donc utiliser le fichier /etc/my.cnf.d/server.cnf pour la configuration du cluster Galera
NODE 1 – 192.168.56.121

[galera]
# Mandatory settings
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address=gcomm://mariadb01,mariadb02,mariadb03
binlog_format=row
default_storage_engine=InnoDB
# innodb
innodb_autoinc_lock_mode=2
innodb_buffer_pool_size=128M
#
# Allow server to accept connections on all interfaces.
#
bind-address=0.0.0.0
#
# Optional setting
#wsrep_slave_threads=1
#innodb_flush_log_at_trx_commit=0
wsrep_cluster_name=cluster01
wsrep_node_address=192.168.56.121 # si eth0 <> @ip utilisée

wsrep_on est positionné à ON., et wsrep_provider est le path des librairies Galera.
binlog_format doit être forcé à ROW (MIXED n’est pas compatible), et le storage est de l’innoDB (myisam n’est pas supporté).
L’adresse utilisée pour ma communication inter-nœuds est la carte eth1, il faut renseigner le paramètre  wsrep_node_address, sinon le cluster ne démarrera pas (eth0 est utilisé par défaut).
 
NODE 2 et NODE 3
La même configuration (excepté wsrep_node_address) est utilisée sur les 3 nœuds.
 
 

Démarrage du cluster

Démarrage du premier nœud et vérification

# Demarrage du cluster sur node mariadb01
[root@mariadb01 my.cnf.d]# sudo galera_new_cluster
[root@mariadb01 my.cnf.d]# ps -ef | grep mysql
mysql 7604 1 4 15:12 ? 00:00:00 /usr/sbin/mysqld --wsrep-new-cluster --wsrep_start_position=00000000-0000-0000-0000-000000000000:-1
root 7650 3887 0 15:12 pts/1 00:00:00 grep --color=auto mysql

 
Vérification :

[root@mariadb01 ~]# mysql -u dba -p
MariaDB [(none)]> show status like '%wsrep_cluster_size%';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| wsrep_cluster_size | 1 |
+--------------------+-------+
1 row in set (0.00 sec)

wsrep_cluster_size indique le nombre de noeuds courant du cluster Galéra,  un seul noeud est démarré.
 

MariaDB [(none)]> SHOW STATUS LIKE 'wsrep_%';
+--------------------------+----------------------+
| Variable_name | Value |
+--------------------------+----------------------+
| wsrep_cluster_conf_id | 18446744073709551615 |
| wsrep_cluster_size | 0 |
| wsrep_cluster_state_uuid | |
| wsrep_cluster_status | Disconnected |
| wsrep_connected | OFF |
| wsrep_local_bf_aborts | 0 |
| wsrep_local_index | 18446744073709551615 |
| wsrep_provider_name | |
| wsrep_provider_vendor | |
| wsrep_provider_version | |
| wsrep_ready | OFF |
| wsrep_thread_count | 0 |
+--------------------------+----------------------+
12 rows in set (0.00 sec)

wsrep_ready est à OFF, un seul nœud ne suffit pas à l’activation du cluster.
 
Pour les autres nœuds, le démarrage se fait par la commande classique :

systemctl start mysqld

 
Ne pas réutiliser le script « galera_new_cluster » sur ces nœuds pour démarrer mysql, sous peine d’initialiser de nouveaux clusters Galera.
 
Après démarrage des services mysql sur tous les nœuds :
Wsrep_ready passe a ON
Wsrep_size = 3 # cluster 3 nodes

[root@mariadb01 ~]# mysql -u dba -p
MariaDB [(none)]> show status like '%wsrep_cluster_size%';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| wsrep_cluster_size | 3 |
+--------------------+-------+
1 row in set (0.00 sec)

 
 

Vérification de la réplication

création de user et database

Nœud mariadb01 :

[root@mariadb01 ~]#  mysql -u dba -pdba
MariaDB [(none)]> create database galera;
Query OK, 1 row affected (0.03 sec)
GRANT ALL PRIVILEGES ON galera.* TO 'dba'@'%' identified by 'dba';
GRANT USAGE ON *.* TO 'dba'@'%';

 
Nœud mariadb02 :

[root@mariadb02 ~]#  mysql -u dba -pdba
MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| galera             |
| information_schema |
| test               |
+--------------------+
3 rows in set (0.00 sec)

 

Chargement de scripts sql

Pour les tests, j’ai chargé les bases de demo sakila
grant all privileges on sakila.* TO ‘dba’@’%’;
Et chargement sous mysql workbench des scripts : sakila-schema.sql, sakila-data.sql
 
Les scripts sont immédiatement répliqués sur les 2 autres bases du cluster.
 

Autres tests

Test du create table as select est également concluant, pas de limitation, et le lock en mode read est autorisé.
 
Egalement, l’utilisation de table sans Primary Key ne pose pas de problème de réplication (sans demande de performance accrue).
Il est bien sur recommandé d’avoir des PK sur l’ensemble des tables, pour de bonnes performances de la réplication et limiter la survenue de deadlock.

Mariadb 03	Mariadb 02
create table table_sanspk (id integer, msg char(10));   insert into table_sanspk values (1,’lib 1′); insert into table_sanspk values (2,’lib 2′); commit                 delete from table_sanspk where id = 1; commit	MariaDB [sakila]> select * from table_sanspk; +——+——-+ | id   | msg   | +——+——-+ |    1 | lib 1 | |    2 | lib 2 | +——+——-+ 2 rows in set (0.00 sec)         MariaDB [sakila]> select * from table_sanspk; +——+——-+ | id   | msg   | +——+——-+ |    2 | lib 2 | +——+——-+ 1 row in set (0.00 sec)

 
 

Conclusion

 
MariaDB et Galera permettent de monter rapidement une architecture haute-disponibilité, répondant à de nombreuses contraintes d’exploitation.
Cette installation est utilisable pour un test mais ne correspond pas aux besoins de production.
 
N’hésitez pas à nous contacter pour vos projets MySQL, mariaDB.
 
 
 

Références  :

http://galeracluster.com/products/
https://mariadb.com/kb/en/library/what-is-mariadb-galera-cluster/