Mise en place d'un cluster de bases de données à haute disponibilité à l'aide de MariaDB Galera, ProxySQL, Keepalived et Debian 13

Introduction

À mesure que vos applications gagnent en envergure et en importance, il devient essentiel de garantir leur disponibilité continue. Les temps d’arrêt des bases de données peuvent entraîner une perte de chiffre d’affaires, la frustration des utilisateurs et nuire à votre réputation. Ce guide explique comment créer un cluster MariaDB hautement disponible (HA) en tirant parti de la réplication Galera, de ProxySQL pour le routage intelligent des requêtes et de Keepalived pour la gestion des adresses IP virtuelles sous Debian.

Cette architecture combine les atouts de chaque technologie pour offrir un environnement de base de données robuste et résilient. MariaDB Galera assure une réplication multi-maître synchrone, garantissant la cohérence des données entre plusieurs nœuds. ProxySQL fait office de routeur de requêtes et d’équilibreur de charge, assurant une gestion intelligente du trafic et allégeant la charge des serveurs de base de données. Keepalived gère une adresse IP virtuelle, offrant un point d’accès unique au cluster et automatisant le basculement en cas de défaillance d’un nœud.

Ce guide suppose une expérience en administration de systèmes Linux, une connaissance des concepts de base des réseaux (TCP/IP, DNS) et une bonne maîtrise de l’administration des bases de données. Nous nous concentrerons sur la configuration et l’intégration de ces technologies au sein d’un environnement Debian.

Principaux avantages de cette architecture :

• Haute disponibilité : le basculement automatisé garantit un temps d’indisponibilité minimal.
• Cohérence des données : la réplication synchrone garantit la cohérence des données sur tous les nœuds.
• Performances améliorées : ProxySQL optimise le routage des requêtes et réduit la charge sur les serveurs de bases de données.
• Gestion simplifiée : une seule adresse IP virtuelle simplifie la configuration et l'accès aux applications.

Ce dont vous aurez besoin :

• Trois VPS ou serveurs Debian 13.
• Un accès root ou sudo à tous les serveurs.
• Une bonne maîtrise de l'interface en ligne de commande.
• Une connaissance de base des réseaux TCP/IP et du DNS.

Prérequis

Interconnexion des nœuds

Une résolution correcte des noms d'hôtes est essentielle au bon fonctionnement du cluster. Chaque serveur doit pouvoir localiser les autres serveurs par leur nom. Nous utilisons des noms d'hôtes pour simplifier la gestion. Les adresses IP des nœuds doivent appartenir au même sous-réseau.

Correspondance entre noms d'hôte et adresses IP

• galera0 (nœud maître) : 192.168.10.10
• galera1 (nœud esclave) : 192.168.10.11
• galera2 (nœud esclave) : 192.168.10.12

Vous pouvez effectuer la résolution des noms d’hôtes soit via le fichier /etc/hosts, soit via le DNS.

• Utilisation du fichier /etc/hosts (configuration plus simple) : cette méthode convient aux environnements de test et de développement. Sur chaque serveur, ajoutez dans le fichier /etc/hosts des entrées associant le nom d'hôte du serveur à son adresse IP statique.
• Utilisation du DNS (recommandée pour la production) : pour les environnements plus vastes ou plus complexes, configurez des enregistrements DNS (enregistrements A) qui associent les noms d’hôte des serveurs à leurs adresses IP respectives.

Vérification

Après avoir configuré la résolution des noms d’hôte, vérifiez que chaque serveur peut résoudre les noms d’hôte des autres serveurs à l’aide de la commande ping. Par exemple, depuis galera0, exécutez ping galera1. Vous devriez recevoir une réponse.

Installation des paquets requis

Avant de pouvoir configurer le cluster Galera, vous devez installer les paquets MariaDB nécessaires sur chaque nœud. Cette section décrit les étapes requises pour les systèmes basés sur Debian.

Ajouter les dépôts requis

Ajoutez les dépôts requis à l’aide des commandes suivantes :

apt-get update && apt-get install -y --no-install-recommends lsb-release wget apt-transport-https ca-certificates

wget -nv -O /usr/share/keyrings/proxysql-3.0.x-keyring.gpg 'https://repo.proxysql.com/ProxySQL/proxysql-3.0.x/repo_pub_key.gpg'

echo "deb [signed-by=/usr/share/keyrings/proxysql-3.0.x-keyring.gpg] https://repo.proxysql.com/ProxySQL/proxysql-3.0.x/bookworm/ ./" | tee /etc/apt/sources.list.d/proxysql.list

Mise à jour du système

Commencez par mettre à jour vos listes de paquets et vos paquets. Exécutez la commande suivante en tant qu'utilisateur root sur chaque nœud :

apt update && apt upgrade -y

Installation des paquets

Installez les paquets requis sur chaque nœud à l'aide de cette commande :

apt install rsync mariadb-server mariadb-client galera-4 proxysql keepalived -y

Sécurisation de l'installation de MariaDB

Exécutez le script de sécurité sur chaque nœud :

sudo mariadb-secure-installation

Ce script effectue deux étapes cruciales : il vous invite à définir un mot de passe root fort pour le serveur MariaDB et supprime toutes les configurations par défaut non sécurisées. Suivez les instructions à l'écran pour mener à bien ce processus.

Activer l'accès à distance à MariaDB

Exécutez ces commandes pour activer l'accès à distance sur chaque nœud :

sed -i "s/.*bind-address.*/bind-address = 0.0.0.0/" /etc/mysql/mariadb.conf.d/50-server.cnf
systemctl restart mariadb

Galera

Galera assure la réplication synchrone des données sur tous les nœuds du cluster. Cela signifie que chaque modification apportée à la base de données sur un nœud est automatiquement et simultanément répercutée sur tous les autres nœuds. Principaux avantages de Galera dans cette configuration :

• Haute disponibilité : si un nœud tombe en panne, les autres nœuds continuent de fournir les données sans interruption. Le cluster désigne automatiquement un nœud encore opérationnel comme nœud principal.
• Cohérence des données : grâce à la réplication synchrone, les données sont toujours cohérentes sur tous les nœuds. Cela élimine le risque de lectures obsolètes : vous lisez toujours la version la plus récente des données.
• Évolutivité en lecture : les données étant répliquées sur plusieurs nœuds, vous pouvez répartir les requêtes de lecture sur l’ensemble du cluster afin d’améliorer les performances de lecture.

En substance, Galera garantit que votre base de données MariaDB reste hautement disponible, cohérente et évolutive – des exigences cruciales pour de nombreuses applications.

Configuration

Créez un fichier de configuration /etc/mysql/conf.d/galera.cnf sur chaque nœud. Le contenu sera identique, à l’exception du nom et de l’adresse de chaque nœud. Collez ce modèle :

[mysqld]
# Basic MariaDB settings
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0 # Binds to all network interfaces. Adjust if you have a specific private IP for cluster traffic.
# Galera Provider Configuration
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so # Adjust path if different (e.g., /usr/lib64/galera-4/libgalera_smm.so)
# Galera Cluster Configuration
wsrep_cluster_name="my_galera_cluster" # A unique name for your cluster
# IP addresses of ALL nodes in the cluster, comma-separated.
# Use private IPs if available for cluster communication.
wsrep_cluster_address="gcomm://galera0,galera1,galera2"
# This node's specific configuration
wsrep_node_name="<node_name>" # Must be unique for each node (e.g., node1, node2, node3)
wsrep_node_address="<node_address>" # This node's own IP address

Remplacez <node_name> et <node_address> sur chaque nœud. Utilisez galera0 pour le premier nœud, et ainsi de suite.

Démarrez le cluster

Démarrez le cluster sur le premier nœud à l’aide de cette commande :

sudo systemctl stop mariadb && sudo galera_new_cluster

Redémarrez MariaDB sur les autres nœuds :

sudo systemctl restart mariadb

Vérifier la configuration

Vérifier la taille du cluster

Connectez-vous à MariaDB sur n'importe quel nœud et vérifiez l'état du cluster. Connectez-vous à la base de données :

sudo mariadb -u root -p

Vérifiez l'état des nœuds du cluster dans le shell MariaDB :

SHOW STATUS LIKE 'wsrep_cluster_size';

wsrep_cluster_size doit être égal au nombre de nos nœuds.

MariaDB [galtest]> SHOW STATUS LIKE
'wsrep_cluster_size';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+
1 row in set (0.001 sec)

MariaDB [galtest]>

Tester la réplication

Créez une base de données de test sur n'importe quel nœud et insérez un message de test. Exécutez les commandes suivantes depuis le shell MariaDB :

CREATE DATABASE galtest;
USE galtest;
CREATE TABLE messages (id INT AUTO_INCREMENT PRIMARY KEY, text VARCHAR(255));
INSERT INTO messages (text) VALUES ('Test from galera0!');

Vérifiez ensuite les données sur les autres nœuds à l'aide de la requête SQL suivante via le shell MariaDB :

USE galtest;
SELECT * FROM messages;

Le message de test devrait s'afficher :

MariaDB [galtest]> USE galtest;
Database changed
MariaDB [galtest]> SELECT * FROM messages;
+----+--------------------+
| id | text               |
+----+--------------------+
|  7 | Test from galera0! |
+----+--------------------+
1 row in set (0.001 sec)

MariaDB [galtest]>

ProxySQL

Dans cette configuration de cluster, ProxySQL est bien plus qu’un simple intermédiaire ; il améliore considérablement les performances, la fiabilité et la facilité de gestion de votre base de données. ProxySQL constitue une couche essentielle entre vos applications et votre cluster Galera. Ses principaux objectifs sont les suivants :

• Mise en cache des requêtes : ProxySQL met activement en cache les requêtes fréquemment exécutées. Au lieu d’interroger à plusieurs reprises le cluster Galera pour obtenir les mêmes données, il fournit le résultat mis en cache, ce qui réduit considérablement la charge de la base de données et améliore les temps de réponse. Cela est particulièrement avantageux pour les applications à forte intensité de lecture.
• Mise en pool des connexions : ProxySQL gère un pool de connexions persistantes vers le cluster Galera. L’établissement d’une connexion à la base de données est une opération gourmande en ressources. La mise en pool des connexions évite cette surcharge en réutilisant les connexions existantes, ce qui améliore encore les performances.
• Équilibrage de charge et routage des requêtes : ProxySQL peut acheminer intelligemment les requêtes vers différents nœuds de votre cluster Galera en fonction de facteurs tels que la charge du serveur, le type de requête ou l’affinité des données. Cela vous permet de répartir la charge de travail et d’optimiser les performances de votre cluster.
• Optimisation des requêtes : ProxySQL peut réécrire les requêtes pour les rendre plus efficaces, en tirant potentiellement parti des capacités de Galera pour une exécution optimale.
• Détection des pannes et routage : ProxySQL surveille en permanence l’état de santé de vos nœuds Galera. En cas de panne d’un nœud, ProxySQL redirige automatiquement les requêtes vers des nœuds opérationnels, garantissant ainsi un service ininterrompu.

En substance, ProxySQL agit comme un gestionnaire de trafic intelligent et un optimiseur de performances pour votre cluster Galera, améliorant considérablement son efficacité et sa résilience.

Précautions

Configuration des utilisateurs

Utilisateur de surveillance

L’utilisateur de surveillance dans ProxySQL est un compte de base de données dédié, réservé exclusivement aux outils de surveillance afin d’accéder en toute sécurité aux statistiques et métriques internes. Il est configuré avec des autorisations minimales – uniquement l’accès SELECT – garantissant ainsi l’intégrité et la sécurité de vos données tout en permettant une surveillance complète des performances.

Exécutez cette requête dans le shell MariaDB sur le nœud maître pour ajouter l’utilisateur de surveillance :

CREATE USER 'monitor'@'%' IDENTIFIED BY 'monitor';
GRANT SELECT ON *.* TO 'monitor'@'%';
FLUSH PRIVILEGES;

Utilisateur d’application

L'utilisateur d'application dans ProxySQL est un compte de base de données standard utilisé par vos applications pour se connecter et exécuter des requêtes sur le cluster Galera sous-jacent. C'est par l'intermédiaire de cet utilisateur que votre application interagit directement avec la base de données, en récupérant et en manipulant les données.

Exécutez cette requête dans le shell MariaDB sur le nœud maître pour ajouter l’utilisateur d’application :

GRANT ALL PRIVILEGES ON *.* TO 'test'@'%' IDENTIFIED BY 'test' WITH GRANT OPTION;
FLUSH PRIVILEGES;

Vérification

Vérifiez la création des utilisateurs sur tous les nœuds à l'aide de cette commande :

mariadb -u root -e "SELECT user, host FROM mysql.user;"

Configuration

Créez un fichier de configuration /etc/proxysql.cnf sur chaque nœud et collez-y le contenu suivant :

datadir="/var/lib/proxysql"

admin_variables=
{
        admin_credentials="admin:admin"
        mysql_ifaces="127.0.0.1:6032"
}

mysql_variables=
{
        threads=4
        max_connections=2048
        monitor_username="monitor"
        monitor_password="monitor"
}

mysql_servers=
(
        { address="galera0" , port=3306 , hostgroup=0 },
        { address="galera1" , port=3306 , hostgroup=0 },
        { address="galera2" , port=3306 , hostgroup=0 }
)

mysql_users=
(
        { username = "test" , password = "test" , default_hostgroup = 0 , active = 1 }
)

mysql_query_rules=
(
        {
                rule_id=2
                active=1
                match_pattern="^SELECT.*"
                destination_hostgroup=0
                apply=1
        }
)

Activez et démarrez ProxySQL à l'aide de ces commandes :

sudo systemctl start proxysql
sudo systemctl enable proxysql
sudo proxysql --reload

Vérifiez la configuration de ProxySQL à l'aide de cette commande :

mysql -u admin -padmin -h 127.0.0.1 -P6032 -e "SELECT hostname, status FROM mysql_servers;"

Tous les nœuds doivent être en ligne :

+----------+--------+
| hostname | status |
+----------+--------+
| galera0  | ONLINE |
| galera1  | ONLINE |
| galera2  | ONLINE |
+----------+--------+

Keepalived

Keepalived gère une adresse IP virtuelle, fournissant un point d'accès unique au cluster et automatisant le basculement en cas de défaillance d'un nœud. Il surveille l'état de santé des nœuds MariaDB et redirige le trafic vers un nœud opérationnel en cas de défaillance, garantissant ainsi une haute disponibilité. La configuration définit l’ID de routeur virtuel 51 et utilise l’interface eth0. Sur le nœud maître, l’état est défini sur MASTER avec une priorité de 100. Les nœuds de secours sont configurés avec un état BACKUP, avec des priorités respectives de 90 et 80. L’adresse `virtual_ipaddress` est définie sur 192.168.10.50 sur tous les nœuds. L’adresse VIP et les nœuds doivent se trouver dans le même sous-réseau. L’hébergeur doit prendre en charge l’adresse VIP pour les VPS. L’authentification est activée avec un mot de passe partagé : 1234. Le paramètre `advert_int` définit la fréquence à laquelle le nœud maître envoie des annonces VRRP. Une valeur plus faible signifie des annonces plus fréquentes, ce qui peut accélérer la détection du basculement ; une valeur plus élevée signifie des annonces moins fréquentes, ce qui peut retarder le basculement mais réduit la charge du réseau.

Configuration

Créez un fichier de configuration /etc/keepalived/keepalived.conf sur chaque nœud et collez-y le contenu suivant :

vrrp_instance VI_1 {
    state <NODE_STATE>
    interface eth0
    virtual_router_id 51
    priority <NODE_PRIORITY>
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1234
    }
    virtual_ipaddress {
        192.168.10.50/24
    }
}

Modifiez <NODE_STATE> et <NODE_PRIORITY> comme décrit ci-dessus. Activez et démarrez le service keepalived :

sudo systemctl enable keepalived && sudo systemctl start keepalived

Vérification

Pour vérifier la configuration, utilisez l’adresse VIP configurée via Keepalived et le port configuré via ProxySQL. Vérifiez par exemple la taille du cluster :

mariadb -u test -ptest -h 192.168.10.50 -P6033 -D galtest -e "SHOW STATUS LIKE 'wsrep_cluster_size';"

La réponse attendue doit correspondre à la vérification Galera :

+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+

Vous pouvez désormais redémarrer les nœuds de manière aléatoire, vérifier la taille du cluster et la disponibilité des données.

Conclusion

Ce guide a montré comment mettre en place un cluster MariaDB hautement disponible en utilisant la réplication Galera, ProxySQL pour le routage des requêtes et Keepalived pour la gestion des adresses IP virtuelles sous Debian. Cette architecture offre plusieurs avantages clés, notamment une haute disponibilité avec basculement automatique, la cohérence des données grâce à la réplication synchrone et des performances améliorées via ProxySQL. En combinant ces technologies, vous pouvez créer un environnement de base de données robuste et résilient, capable de gérer des charges de travail accrues et de minimiser les temps d’arrêt.