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.

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

3 machines BDD qui seront nommée :

• galera01.oowy.lan (192.168.1.80)
• galera02.oowy.lan (192.168.1.81)
• galera03.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

Tout nos nœuds seront accessible sur le réseaux en Lecture/Écriture.

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.

root@galera01:~# mkdir /etc/systemd/system/mariadb.service.d/
root@galera01:~# nano /etc/systemd/system/mariadb.service.d/limitnofile.conf
...
[Service]
 
LimitNOFILE=infinity

On recharge systemd pour prendre en charge la modification.

root@galera01:~# systemctl daemon-reload

Par défaut, le système limite la taille des fichiers de base qui peuvent être créés. Il y a une limite soft et une limite hard. Sur de nombreux systèmes, la limite soft est fixée par défaut à 0. Si vous souhaitez activer les core dumps, vous devrez peut-être l'augmenter.

Par conséquent, vous pouvez avoir besoin d'augmenter les limites soft et hard.

root@galera01:~# mkdir /etc/systemd/system/mariadb.service.d/
root@galera01:~# nano /etc/systemd/system/mariadb.service.d/limitcore.conf
...
[Service]
 
LimitCORE=infinity

On recharge systemd pour prendre en charge la modification.

root@galera01:~# systemctl daemon-reload

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

Pour une performance optimale des I/O dans une base de données, nous utilisons le planificateur noop. Les programmateurs recommandés sont le noop et le deadline. Vous pouvez vérifier les paramètres de votre planificateur avec :

# cat /sys/block/${DEVICE}/queue/scheduler

Pour le changer à la volée.

# echo noop > /sys/block/hda/queue/scheduler

Chnager le scheduler au boot en éditant le fichier “/etc/default/grub” et en rajouter la chaine “elevator=noop” à 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 elevator=noop"
 
[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 ~]# 

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

[root@galera01 ~]# apt install socat

Il est évident que l'accès à la mémoire d'échange à partir du disque est beaucoup plus lent que l'accès direct à la mémoire vive. C'est particulièrement mauvais sur un serveur de base de données car :

• Les algorithmes internes de MariaDB supposent que la mémoire n'est pas swap, et sont très inefficaces si c'est le cas. Certains algorithmes sont destinés à éviter ou à retarder les entrées/sorties de disque et à utiliser la mémoire lorsque c'est possible - faire cela avec l'échange peut être pire que de le faire sur disque.
• L'échange augmente les entrées/sorties par rapport à l'utilisation du disque au départ, car les pages sont échangées activement entre les deux systèmes. Même une opération comme la suppression d'une page sale qui ne sera plus stockée en mémoire, bien qu'elle soit conçue pour améliorer l'efficacité, coûtera plus cher en cas d'échange.
• Les verrous de base de données sont particulièrement inefficaces en cas d'échange. Ils sont conçus pour être obtenus et libérés souvent et rapidement, et le fait de s'arrêter pour effectuer des E/S sur disque aura un impact sérieux sur leur utilisation.

La principale façon d'éviter l'échange est de s'assurer que l'on dispose de suffisamment de mémoire vive pour tous les processus qui doivent être exécutés sur la machine. Un réglage trop élevé des variables système peut signifier que, sous charge, le serveur manque de mémoire et doit utiliser le swap. Il est donc essentiel de comprendre les paramètres à utiliser et leur impact sur l'utilisation de la mémoire de votre serveur.

Il est recommandé d'utiliser un paramètre faible pour la charge de travail de la base de données. Pour les bases de données MariaDB, il est recommandé de fixer la valeur de swappiness à 1.

# nano /etc/sysctl.conf
...
vm.swappiness = 1

On recharge la configuration avec la commande “sysctl”

# sysctl -p

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.

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.

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 les autres nœuds avec :

systemctl start mariadb.service

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.

Pour valider le fonctionnement du cluster, nous allons simplement créer une base de donnée et vérifier que celle-ci se réplique bien sur les deux autres nœuds du cluster.

Sur le premier nœud du cluster “galera01.oowy.lan”

[root@galera01 ~]#  mysql -u root -p
MariaDB [(none)]> create database galera;
Query OK, 1 row affected (0.058 sec)
 
MariaDB [(none)]> GRANT ALL PRIVILEGES ON galera.* TO 'dba'@'%' identified by 'dba';
Query OK, 0 rows affected (0.019 sec)
 
MariaDB [(none)]> GRANT USAGE ON *.* TO 'dba'@'%';
Query OK, 0 rows affected (0.024 sec)

On se connecte sur un autre nœud du cluster “galera02.oowy.lan”

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| galera             |
| information_schema |
| mysql              |
| performance_schema |
+--------------------+
4 rows in set (0.001 sec)

Si vous devez redémarrer l'ensemble du cluster, vous devez commencer par le dernier nœud qui était en panne.

Pour redémarrer le cluster MariaDB Galera, suivez les étapes ci-dessous :

• Identifiez quel nœud a l'ID d'état le plus avancé.
• Commencez par le nœud le plus avancé.
• Démarrez le reste des nœuds.

Pour identifier quel nœud a l'ID d'état de nœud le plus avancé (seqno), ouvrez le fichier suivant dans chaque nœud : /var/lib/mysql/grastate.dat.

Vérifiez ensuite la valeur du safe_to_bootstrap.

Si cette valeur est égale à 1, il s'agit du nœud à partir duquel vous pouvez redémarrer le cluster.

Si la valeur de safe_to_bootstrap est égale à -1, il s'agit d'un nœud planté. Dans le cas où tous les nœuds sont plantés, vous devrez effectuer une restauration de la base de données.

https://galeracluster.com

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

https://mariadb.com/kb/en/systemd/#configuring-the-core-file-size

https://mariadb.com/kb/en/configuring-mariadb-for-optimal-performance/