Configuration d'un cluster de base de données haute disponibilité en utilisant MariaDB Galera, ProxySQL, Keepalived et Debian 13.

Introduction

À mesure que vos applications prennent de l'ampleur et de l'importance, garantir une disponibilité continue devient crucial. Les temps d'arrêt de la base de données peuvent entraîner une perte de revenus, des utilisateurs frustrés et nuire à votre réputation. Ce guide montre comment construire un cluster MariaDB hautement disponible (HA) en utilisant la réplication Galera, ProxySQL pour le routage intelligent des requêtes et Keepalived pour la gestion des IP virtuelles sur Debian.

Cette architecture combine les forces de chaque technologie pour offrir un environnement de base de données robuste et résilient. MariaDB Galera fournit une réplication multi-maître synchrone, garantissant la cohérence des données sur plusieurs nœuds. ProxySQL agit comme un routeur de requêtes et un équilibrage de charge, offrant une gestion intelligente du trafic et déchargeant les serveurs de base de données. 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 de nœud.

Ce guide suppose une expérience en administration système Linux, des concepts de base en réseau (TCP/IP, DNS) et une familiarité avec l'administration de bases de données. Nous nous concentrerons sur la configuration et l'intégration de ces technologies dans un environnement Debian.

Principaux avantages de cette architecture :

• Haute disponibilité : Le basculement automatisé assure un temps d'arrêt minimal.
• Cohérence des données : La réplication synchrone garantit la cohérence des données sur tous les nœuds.
• Amélioration des performances : ProxySQL optimise le routage des requêtes et réduit la charge sur les serveurs de base de données.
• Gestion simplifiée : Une seule adresse IP virtuelle simplifie la configuration et l'accès des applications.

Ce dont vous aurez besoin :

• Trois VPS ou serveurs Debian 13.
• Accès root ou sudo à tous les serveurs.
• Familiarité avec l'interface en ligne de commande.
• Une compréhension de base du réseau TCP/IP et du DNS.

Prérequis

Interconnexion des nœuds

Une résolution correcte des noms d'hôte est essentielle pour que le cluster fonctionne correctement. Chaque serveur doit pouvoir trouver les autres serveurs par leur nom. Nous utilisons des noms d'hôte pour simplifier la gestion. Les adresses IP des nœuds doivent être dans le même sous-réseau.

Mapping des noms d'hôte et des 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 réaliser la résolution des noms d'hôte en utilisant soit /etc/hosts soit le DNS.

• Utilisation de /etc/hosts (Configuration plus simple) : Cela convient aux environnements de test et de développement. Sur chaque serveur, ajoutez des entrées mappant le nom d'hôte du serveur à son adresse IP statique dans le fichier /etc/hosts.
• Utilisation du DNS (Recommandé pour la production) : Pour des environnements plus grands ou plus complexes, configurez des enregistrements DNS (enregistrements A) qui mappent 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 en utilisant 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 devrez 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 en utilisant les 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

Tout d'abord, mettez à jour vos listes de paquets et vos paquets. Exécutez la commande suivante en tant que root sur chaque nœud :

apt update && apt upgrade -y

Installer les paquets

Installez les paquets requis sur chaque nœud en utilisant cette commande :

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

Sécuriser 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 demandera de définir un mot de passe root fort pour le serveur MariaDB et supprimera toute configuration par défaut non sécurisée. Suivez les invites à l'écran pour terminer ce processus.

Activer l'accès distant à MariaDB

Exécutez ces commandes pour activer l'accès distant 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 fournit une 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 propagée à tous les autres nœuds. Les principaux avantages de Galera dans cette configuration :

• Haute disponibilité : Si un nœud échoue, les autres nœuds continuent de servir les données sans interruption. Le cluster promeut automatiquement un nœud survivant pour devenir le 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 à jour des données.
• Évolutivité en lecture : Étant donné que les données sont répliquées sur plusieurs nœuds, vous pouvez distribuer les requêtes de lecture sur le cluster pour augmenter les performances de lecture.

En essence, 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]
# Paramètres de base de MariaDB
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0

# Configuration du fournisseur Galera
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so

# Configuration du cluster Galera
wsrep_cluster_name="my_galera_cluster"
wsrep_cluster_address="gcomm://galera0,galera1,galera2"

# Configuration spécifique à ce nœud
wsrep_node_name="<node_name>"
wsrep_node_address="<node_address>"

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

Démarrer le cluster

Démarrez le cluster sur le premier nœud en utilisant 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.

+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+
1 row in set (0.001 sec)

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!');

Ensuite, vérifiez les données sur les autres nœuds en utilisant la requête SQL suivante via le shell MariaDB :

USE galtest;

SELECT * FROM messages;

Le message de test devrait apparaître :

+----+--------------------+
| id | text               |
+----+--------------------+
|  7 | Test from galera0! |
+----+--------------------+
1 row in set (0.001 sec)

ProxySQL

ProxySQL dans cette configuration de cluster est plus qu'un simple intermédiaire ; il améliore considérablement les performances, la fiabilité et la gestion de votre base de données. ProxySQL se situe comme une couche cruciale entre votre ou vos applications et votre cluster Galera. Ses principaux objectifs sont :

• Mise en cache des requêtes : ProxySQL met en cache de manière agressive les requêtes fréquemment exécutées. Au lieu de requêter à plusieurs reprises le cluster Galera pour les mêmes données, il sert le résultat mis en cache, réduisant considérablement la charge de la base de données et améliorant les temps de réponse. Cela est particulièrement bénéfique pour les applications à forte lecture.
• Pooling de connexions : ProxySQL maintient un pool de connexions persistantes au cluster Galera. Établir une connexion à la base de données est une opération gourmande en ressources. Le pooling de connexions évite cette surcharge en réutilisant les connexions existantes, augmentant ainsi les performances.
• Équilibrage de charge et routage des requêtes : ProxySQL peut router 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 distribuer la charge de travail et de maximiser les performances de votre cluster.
• Optimisation des requêtes : ProxySQL peut réécrire les requêtes pour être plus efficaces, en exploitant potentiellement les capacités de Galera pour une exécution optimale.
• Détection des pannes et routage : ProxySQL surveille en continu la santé de vos nœuds Galera. Si un nœud échoue, ProxySQL redirige automatiquement les requêtes vers des nœuds sains, garantissant un service ininterrompu.

En essence, 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é uniquement aux outils de surveillance pour accéder en toute sécurité aux statistiques et métriques internes. Il est configuré avec des autorisations minimales – juste un accès SELECT – garantissant 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 contre le cluster Galera sous-jacent. C'est par cet utilisateur que votre application interagit directement avec la base de données, récupérant et 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 en utilisant 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 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 en utilisant ces commandes :

sudo systemctl start proxysql

sudo systemctl enable proxysql

sudo proxysql --reload

Vérifiez votre configuration ProxySQL en utilisant 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 de nœud. Il surveille la santé des nœuds MariaDB et redirige le trafic vers un nœud sain si une défaillance se produit, maintenant ainsi une haute disponibilité. La configuration définit l'ID du 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 sauvegarde sont configurés avec un état de BACKUP, ayant des priorités de 90 et 80 respectivement. L'adresse IP virtuelle est définie sur 192.168.10.50 sur tous les nœuds. Le VIP et les nœuds doivent être dans le même sous-réseau. L'hébergement doit prendre en charge le VIP pour les VPS. L'authentification est activée avec un mot de passe partagé de 1234. Le paramètre advert_int définit la fréquence à laquelle le nœud maître envoie des annonces VRRP. Une valeur plus basse signifie des annonces plus fréquentes, accélérant potentiellement la détection de basculement ; une valeur plus élevée signifie des annonces moins fréquentes, retardant potentiellement le basculement mais réduisant la surcharge réseau.

Configuration

Créez un fichier de configuration /etc/keepalived/keepalived.conf sur chaque nœud et collez 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
    }
}

Changez <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 le VIP configuré via Keepalived et le port configuré via ProxySQL. Vérifiez la taille du cluster par exemple :

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 de Galera :

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

Vous pouvez maintenant redémarrer les nœuds au hasard, vérifier la taille du cluster et la disponibilité des données.

Conclusion

Ce guide a démontré comment construire un cluster MariaDB hautement disponible en utilisant la réplication Galera, ProxySQL pour le routage des requêtes et Keepalived pour la gestion des IP virtuelles sur Debian. Cette architecture offre plusieurs avantages clés, notamment une haute disponibilité avec basculement automatisé, une cohérence des données grâce à la réplication synchrone et une amélioration des performances via ProxySQL. En combinant ces technologies, vous pouvez construire 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.