MariaDB offre deux solutions différentes de haute disponibilité (HA) et de clustering.

• La première est la réplication standard MariaDB maître/esclave qui peut être configurée dans différentes topologies, principalement pour l'équilibrage de charge, la HA et la sauvegarde.
• La seconde est MariaDB Galera, une solution de clustering synchrone multi-maîtres.

Ses principales caractéristiques sont les suivantes :

• Multi-maître : Tous les nœuds d'un cluster Galera peuvent effectuer des opérations de lecture et d'écriture, offrant ainsi une meilleure évolutivité.
• Les nœuds peuvent rejoindre une grappe automatiquement, et sont expulsés en cas d'échec.
• La réplication Galera est synchrone, ce qui signifie que les changements sur un nœud sont garantis pour être appliqués sur les autres nœuds. En théorie, cela garantit qu'aucune donnée n'est perdue en cas de défaillance d'un nœud.

Nous utiliserons trois nœuds Debian 10, bien que n'importe quel nombre (≥3) de nœuds puisse être utilisé. La configuration de deux nœuds dans une grappe Galera est techniquement possible mais n'offre pas de tolérance aux pannes car un nœud défaillant entraînera l'arrêt de l'autre nœud.

MariaDB Server est l'un des serveurs de bases de données les plus populaires au monde. Il a été créé par les développeurs originaux de MySQL et garantit de rester open source.

MariaDB transforme les données en informations structurées dans un large éventail d'applications, allant des opérations bancaires aux sites Web. MariaDB est utilisé parce qu'il est rapide, évolutif et robuste, avec un riche écosystème de moteurs de stockage, de plugins et de nombreux autres outils, qui le rendent très polyvalent pour une grande variété de cas d'utilisation.

MariaDB est développé en tant que logiciel open source sous licence GPL et en tant que base de données relationnelle, il fournit une interface SQL pour accéder aux données. Les dernières versions de MariaDB incluent également des fonctionnalités SIG et JSON.

En 2009, à la suite du rachat de MySQL par Sun Microsystems et des annonces du rachat de Sun Microsystems par Oracle Corporation, Michael Widenius, fondateur de MySQL, quitte cette société pour lancer le projet MariaDB, dans une démarche visant à remplacer MySQL tout en assurant l’interopérabilité.

Il s'agit donc d'un fork communautaire de MySQL : la gouvernance du projet est assurée par la fondation MariaDB, et sa maintenance par la société Monty Program AB, créateur du projet. Cette gouvernance confère au logiciel l’assurance de rester libre.

Vous trouverez plus d'informations dans la base de connaissances MariaDB.

L'objectif ici est de préparer un cluster MariaDB Galera multi-maître synchrone pour MariaDB, à savoir que chaque noeud du cluster pourra être utilisé aussi bien en lecture qu'en écriture, la réplication des données devant être déployés sur chacun des noeuds. A la différence que dans notre situation nous n'aurons que deux noeuds de BDD, le troisieme sera en réalité un arbitre.

Il est disponible sous Linux uniquement et ne prend en charge que les moteurs de stockage XtraDB / InnoDB.

Caractéristiques :

• Réplication synchrone
• Topologie multi-maîtres active-active
• Lire et écrire sur n'importe quel noeud de cluster
• Contrôle d'appartenance automatique, les noeuds défaillants sont supprimés du cluster
• Jointure automatique de noeud
• Véritable réplication parallèle, au niveau de la ligne
• Connexions client directes, apparence native de MariaDB

Avantages :

Les fonctionnalités ci-dessus présentent plusieurs avantages pour une solution de clustering de SGBD, notamment:

• Pas de retard d'esclave
• Aucune transaction perdue
• Evolutivité en lecture et en écriture
• Latences client plus petites

Lorsque vous déployez un cluster Galera, il est recommandé d'utiliser au moins trois instances : Trois nœuds, trois centres de données, etc.

Si le coût de l'ajout de ressources (par exemple, un troisième centre de données) est trop élevé, vous pouvez utiliser Galera Arbitrator. Galera Arbitrator est membre d'un cluster qui participe au vote, mais pas à la réplication proprement dite.

Galera Arbitrator a deux objectifs :

• Lorsque vous avez un nombre pair de nœuds, il fonctionne comme un nœud impair, pour éviter les situations de split-brain.
• Il peut également demander un instantané cohérent de l'état des applications, ce qui est utile pour effectuer des sauvegardes.

2 machines BDD qui seront nommée :

• galera01.oowy.lan (192.168.1.80)
• galera02.oowy.lan (192.168.1.81)

1 Arbitre qui sera nommée :

• arbitrator01.oowy.lan (192.168.1.82)

Chaque noeud requiert au minimum :

• 1GHz 1 CPU
• 512Mo de RAM
• 100 Mbps de connexion réseau

Dans notre test, nous disposerons de :

• 1 CPU
• 2Go de RAM
• 100 Mbps de connexion réseau

Le cluster Galera nécessite une communication constante entre tous les nœuds grâce à l'utilisation de la réplication synchrone et ils communiquent entre eux en utilisant les ports TCP suivants.

• 3306 (standard MariaDB port)
• 4444 (SST port)
• 4567 (Galera replication port)
• 4568 (IST port)

Le serveur MariaDB a besoin d'avoir un très grand nombre de descripteurs de fichiers ouvert, il vous faudra donc augmenter les valeurs des limites systèmes.

Pour cela, éditez le fichier “/etc/Security/limits.conf” et rajouter les 2 lignes suivantes:

[root@galera01~]# nano /etc/security/limits.conf
...
mysql            soft    nofile          65535
mysql            hard    nofile          65535

Désactiver les “transparent_hugepage” au boot en éditant le fichier “/etc/default/grub”. Et rajouter la chaine “transparent_hugepage=never” à la ligne GRUB_CMDLINE_LINUX:

[root@galera01~]# cat /etc/default/grub 
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX="transparent_hugepage=never"
 
[root@galera01 ~]# grub-mkconfig -o /boot/grub/grub.cfg
grub-mkconfig -o /boot/grub/grub.cfg 
Création du fichier de configuration GRUB…
Image Linux trouvée : /boot/vmlinuz-4.19.0-8-amd64
Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-8-amd64
Image Linux trouvée : /boot/vmlinuz-4.19.0-6-amd64
Image mémoire initiale trouvée : /boot/initrd.img-4.19.0-6-amd64
done
 
[root@galera01 ~]# 

Pour vous éviter de faire un reboot, vous pouvez les désactiver à chaud, comme ceci:

[root@galera01 ~]# echo never > /sys/kernel/mm/transparent_hugepage/enabled
[root@galera01 ~]# echo never > /sys/kernel/mm/transparent_hugepage/defrag

Un package sur Debian peux-être nécessaires, socat. Il faudra l'installer sur chaque noeud MariaDB.

[root@galera01 ~]# apt install socat

Utilisez les commandes suivantes pour installer MariaDB, la bibliothèque Galera et Rsync. Cette dernière est utilisée par Galera.

[root@galera01 ~]# apt update
[root@galera01 ~]# apt install -y mariadb-server mariadb-client galera-3 rsync

Assurez-vous que le service MariaDB est activé :

[root@galera01 ~]# systemctl enable mariadb.service

Sécurisez vos instances MariaDB en utilisant le script d'installation mysql_secure_installation :

[root@galera01 ~]# mysql_secure_installation

Répondez aux questions comme indiqué ci-dessous et assurez-vous de choisir un mot de passe fort pour l'utilisateur root de MySQL.

Enter current password for root (enter for none): Press <Enter>
Set root password? [Y/n] y
New password: your_password
Re-enter new password: your_password
Remove anonymous users? [Y/n] y
Disallow root login remotely? [Y/n] y
Remove test database and access to it? [Y/n] y
Reload privilege tables now? [Y/n] y
All done!  If you've completed all of the above steps, your MariaDB
installation should now be secure.

Arrêtez le service MariaDB sur tous les nœuds :

systemctl stop mariadb.service

Par défaut, le démon MariaDB n'écoute que les connexions sur l'hôte local. Pour que le cluster fonctionne, il doit être remplacé par une adresse accessible de l'extérieur.

Pour ce faire, modifiez le fichier d'options /etc/mysql/mariadb.conf.d/50-server.cnf : Trouvez la ligne suivante :

bind-address = 127.0.0.1

Si vous utilisez un réseau privé pour le cluster et que vous ne voulez pas exposer MariaDB à d'autres réseaux (par exemple WAN), indiquez l'adresse IPv4 locale pour chaque nœud. Sinon, utilisez 0.0.0.0 qui indique à MariaDB d'écouter sur toutes les interfaces.

Par exemple :

bind-address = 0.0.0.0

Enregistrez la modification et quittez votre éditeur de texte.

Nous allons maintenant configurer les options relatives aux clusters.

Créez un nouveau fichier d'options :

nano /etc/mysql/mariadb.conf.d/99-cluster.cnf

Entrez la configuration sensible suivante dans le fichier, en remplaçant les adresses IP. Elle doit être identique sur tous les nœuds.

[galera]
 
wsrep_on = on 
wsrep_provider = /lib/galera/libgalera_smm.so 
wsrep_cluster_address = gcomm://192.168.1.80,192.168.1.81,192.168.1.82 
wsrep_cluster_name = galera_cluster_0 
 
default_storage_engine = InnoDB 
innodb_autoinc_lock_mode = 2 
innodb_doublewrite = 1 
 
binlog_format = ROW

• wsrep_on : on permet la réplication des jeux d'écriture, la fonctionnalité sous-jacente utilisée par Galera.
• wsrep_provider : spécifie le chemin d'accès à la bibliothèque Galera. Il est fourni par le paquet galera-3 à l'adresse /lib/galera/libgalera_smm.so sous Debian 10.
• wsrep_cluster_address : doit contenir au moins une adresse d'un autre membre du cluster. Il est recommandé de lister tous les membres du cluster. Aucun ordre particulier n'est nécessaire.
• wsrep_cluster_name : doit être unique au cluster et doit être identique sur tous les nœuds du même cluster galera.

Les autres options sont nécessaires au bon fonctionnement de Galera et ne doivent pas être modifiées.

Maintenant que l'on a installer MariaDB sur les 2 noeuds de base de données, il nous faut installer le package Galera Arbitrator sur notre noeud qui fera office d'arbitre.

Pour cela :

# apt install galera-arbitrator-3

# nano /etc/default/garb
...
 
# A comma-separated list of node addresses (address[:port]) in the cluster
GALERA_NODES="192.168.1.236:4567,192.168.1.62:4567,192.168.1.140:4567"
 
# Galera cluster name, should be the same as on the rest of the nodes.
GALERA_GROUP="galera_cluster_0"
...

• GALERA_NODES : doit contenir au moins une adresse d'un autre membre du cluster. Il est recommandé de lister tous les membres du cluster. Aucun ordre particulier n'est nécessaire.
• GALERA_GROUP : doit être unique au cluster et doit être identique sur tous les nœuds du même cluster galera.

Assurez-vous que MariaDB est arrêté/inactif sur tous les nœuds avant de continuer :

systemctl status mariadb.service

Pour démarrer le cluster, un nœud doit d'abord le créer. Sous Debian 10, cela peut être fait avec le script galera_new_cluster. Le script ne doit être exécuté que sur un seul nœud, et une seule fois pour initialiser le cluster.

galera_new_cluster

Cela lancera MariaDB sur le nœud actuel. Assurez-vous qu'il fonctionne avec :

systemctl status mariadb.service

Vérification

[root@galera01 ~]# mysql -u root -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 nœuds courant du cluster Galera. Pour le moment, un seul nœud est démarré.

Ensuite, démarrez MariaDB sur le second nœud avec :

systemctl start mariadb.service

Il ne nous reste plus qu'à démarrer le service “garb” galera arbitrator sur notre noeud arbitre.

# systemctl start garb

Le cluster est maintenant être opérationnel.

MariaDB [(none)]> show status like '%wsrep_cluster_size%';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+
1 row in set (0.003 sec)

wsrep_cluster_size indique le nombre de noeuds courant du cluster Galera,soit 3 (2 bdd + 1 arbitre).

https://galeracluster.com

https://mariadb.com/kb/en/configuring-linux-for-mariadb/