Présentation

MHA (Master High Availability) est une solution éprouvée pour assurer la haute disponibilité des bases de données MySQL. Développé à l'origine par DeNA, cet ensemble d'outils permet un basculement automatique et rapide vers un nouveau nœud maître en cas de panne, garantissant ainsi une continuité de service optimale. Lors d'un incident, MHA peut réaliser la promotion d'un esclave en moins de 30 secondes tout en préservant au maximum la cohérence des données.

L'architecture logicielle se compose de deux éléments distincts : MHA Manager, qui supervise un ou plusieurs clusters de réplication, et MHA Node, qui s'exécute sur chaque serveur MySQL. Le Manager détecte les pannes du maître, identifie l'esclave le plus à jour, le promeut, et reconfigure les autres esclaves pour se synchroniser avec ce nouveau maître. Ce processus est totalement transparent pour les applications.

Afin de minimiser la perte de données en cas de défaillance matérielle du maître, MHA tente de récupérer les événements du journal binaire (binlog) depuis le serveur défaillant. La mise en œuvre de la réplication semi-synchrone de MySQL 5.5 et versions ultérieures est vivement recommandée pour renforcer la sécurité des données. MHA fonctionne avec n'importe quel moteur de stockage compatible avec la réplication maître-esclave.

La configuration minimale recommandée est une architecture avec un maître et deux esclaves. Un cluster à un maître et un seul esclave est fonctionnel, mais les capacités de récupération sont limitées si le maître subit une panne matérielle complète. Dans ce cas de figure, le basculement reste possible si le processus mysqld est simplement arrêté.

Le fonctionnement de MHA peut être résumé aux étapes suivantes :

1. Récupérer les événements du binlog depuis le maître en panne.
2. Identifier l'esclave ayant reçu les données les plus récentes.
3. Appliquer les journaux de relais (relay logs) manquants aux autres esclaves.
4. Appliquer les événements du binlog récupérés sur tous les esclaves.
5. Promouvoir un esclave au statut de nouveau maître.
6. Reconfigurer les autres esclaves pour qu'ils se connectent au nouveau maître.

L'ensemble Manager contient des utilitaires de supervision et de basculement, tandis que le package Node fournit des outils de sauvegarde et d'application des logs, généralement appelés automatiquement par le Manager.

Environnement de test

Pour cet exemple, quatre serveurs CentOS 7.5 sont utilisés :

• gestionnaire (192.168.1.6) : Héberge MHA Manager et MHA Node.
• maitre-principal (192.168.1.7) : Serveur MySQL maître avec MHA Node.
• esclave-candidat (192.168.1.8) : Serveur esclave configuré comme candidat maître, avec MHA Node.
• esclave-secondaire (192.168.1.9) : Serveur esclave standard avec MHA Node.

Installation du composant Node sur tous les serveurs

Les dépendances Perl requises doivent être installées en premier :

yum -y install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager

Si l'erreur concernant libmysqlclient.so.18 apparaît, installer le paquet mysql-community-libs-compat.

Ensuite, installer le binaire MHA Node à partir du paquet RPM préalablement obtenu :

rpm -ivh mha4mysql-node-0.57-0.el7.noarch.rpm

Les exécutables du Node (save_binary_logs, apply_diff_relay_logs, etc.) seront installés dans /usr/bin.

Installation du composant Manager sur le nœud de gestion

Sur le serveur dédié à la gestion, installer le paquet RPM du Manager. Les dépendances ayant été satisfaites par l'installation du Node :

rpm -ivh mha4mysql-manager-0.57-0.el7.noarch.rpm

Configuration de l'authentification par clé SSH

Le nœud de gestion doit pouvoir se connecter en SSH sans mot de passe à tous les serveurs du cluster. De plus, une connexion SSH mutuelle sans mot de passe doit être établie entre les nœuds de données (maître et esclaves).

Générer une paire de clés sur chaque serveur avec la commande ssh-keygen. Puis, distribuer les clés publiques. Par exemple, depuis le gestionnaire (gestionnaire) vers les autres nœuds :

ssh-copy-id 192.168.1.7
ssh-copy-id 192.168.1.8
ssh-copy-id 192.168.1.9

Répéter l'opération de distribution de clés depuis maitre-principal vers les esclaves, et réciproquement, afin que tous les nœuds puissent communiquer entre eux par SSH sans mot de passe.

Configuration de la réplication maître-esclave

Sur le serveur maître (maitre-principal) :

Créer une base de données de test et les utilisateurs dédiés à la réplication et à la surveillance :

CREATE DATABASE test_db;
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'192.168.1.%' IDENTIFIED BY 'MotDePasse123!';
GRANT ALL PRIVILEGES ON *.* TO 'mha_monitor'@'192.168.1.%' IDENTIFIED BY 'MotDePasse456!';
FLUSH PRIVILEGES;

Modifier le fichier de configuration MySQL (my.cnf) pour activer le journal binaire et définir un identifiant unique :

[mysqld]
server-id=1
log-bin=mysql-bin-prim
binlog-do-db=test_db

Redémarrer le service MySQL et noter la position du journal binaire avec SHOW MASTER STATUS;. Ouvrir le port TCP 3306 dans le pare-feu si nécessaire.

Sur le serveur esclave candidat (esclave-candidat) :

Ce serveur agit à la fois comme esclave et comme maître de secours potentiel. Sa configuration doit donc inclure les journaux binaires.

[mysqld]
server-id=2
log-bin=mysql-bin-esclave1
binlog-do-db=test_db
log-slave-updates=1

Après avoir créé la base test_db et les mêmes utilisateurs que sur le maître, configurer la réplication pointant vers maitre-principal :

STOP SLAVE;
CHANGE MASTER TO
    MASTER_HOST='192.168.1.7',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='MotDePasse123!',
    MASTER_LOG_FILE='mysql-bin-prim.000001',
    MASTER_LOG_POS=154; -- Position notée sur le maître
START SLAVE;

Vérifier l'état de la réplication (SHOW SLAVE STATUS\G). Pour terminer, mettre le serveur en lecture seule et désactiver la purge automatique des journaux de relais :

SET GLOBAL read_only = 1;
SET GLOBAL relay_log_purge = 0;

Sur le serveur esclave secondaire (esclave-secondaire) :

Sa configuration est plus simple. Définir un server-id unique (ex: 3), créer l'utilisateur de surveillance (mha_monitor), puis configurer la réplication vers maitre-principal de la même manière que pour l'esclave candidat. Appliquer également read_only=1 et relay_log_purge=0.

Configuration de MHA Manager

Sur le nœud de gestion, créer les répertoires de travail :

mkdir -p /etc/masterha
mkdir -p /var/log/masterha/app1

Créer un script Perl pour gérer le basculement d'une adresse IP virtuelle (VIP), par exemple /usr/local/bin/vip_failover.pl. Ce script doit gérer les actions start (ajouter la VIP au nouveau maître) et stop (retirer la VIP de l'ancien maître). Le chemin vers la commande ip addr et le nom de l'interface réseau doivent être adaptés à l'environnement.

Créer le fichier de configuration principal /etc/masterha/app1.cnf. Ce fichier détaille les paramètres généraux et liste les serveurs du cluster :

[server default]
manager_workdir=/var/log/masterha/app1
manager_log=/var/log/masterha/app1/manager.log
master_binlog_dir=/var/lib/mysql
master_ip_failover_script=/usr/local/bin/vip_failover.pl
user=mha_monitor
password=MotDePasse456!
ping_interval=3
repl_user=repl_user
repl_password=MotDePasse123!
ssh_user=root

[server1]
hostname=192.168.1.7
port=3306

[server2]
hostname=192.168.1.8
port=3306
candidate_master=1
check_repl_delay=0

[server3]
hostname=192.168.1.9
port=3306

Vérification et démarrage du monitoring

Lancer les tests de connectivité SSH et de réplication depuis le nœud de gestion :

masterha_check_ssh --conf=/etc/masterha/app1.cnf
masterha_check_repl --conf=/etc/masterha/app1.cnf

Une fois tous les tests validés, démarrer le Manager en arrière-plan :

nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/masterha/app1/manager.log 2>&1 &

Vérifier son statut avec masterha_check_status --conf=/etc/masterha/app1.cnf.

Test de basculement automatique

Arrêter le service MySQL sur le serveur maître (maitre-principal) pour simuler une panne.

Consulter le journal du Manager (/var/log/masterha/app1/manager.log). On y observe la séquence de basculement : récupération des logs, promotion de esclave-candidat comme nouveau maître, et reconfiguration de esclave-secondaire pour suivre ce nouveau maître.

Le fichier de configuration app1.cnf est automatiquement mis à jour : la section [server1] correspondant à l'ancien maître a été supprimée.

Sur le nouveau maître (esclave-candidat), la commande SHOW MASTER STATUS; confirme qu'il a bien généré ses propres journaux binaires.