Réalisation : Réplication MariaDB - Paul BARRAULT-GAUTIER

Contexte et Objectifs

Contexte et Risque

Dans le cadre de l'optimisation d'une infrastructure Web, j'ai identifié que la base de données constituait un SPOF (Single Point of Failure). Même avec des serveurs web redondants, l'arrêt du serveur de base de données rendrait l'application inutilisable (impossible d'afficher des produits ou d'enregistrer des commandes).

Le risque majeur est la perte de données transactionnelles et l'interruption prolongée de l'activité.

Objectifs du Projet

Haute Disponibilité (HA) : Garantir que les données restent accessibles même en cas de défaillance matérielle ou logicielle du serveur principal.
Intégrité des données : Assurer une synchronisation parfaite et en temps réel entre deux instances de bases de données.
Plan de Continuité d'Activité (PCA) : Définir une procédure de bascule pour rétablir le service rapidement.

Environnement Technique

2 serveurs Debian 11/12
MariaDB (SGBD)
Réplication Master-Slave
Journalisation binaire (log-bin)
Utilisateur dédié réplication

Réalisation des Tâches

1. Préparation du Serveur Master

Installation : Déploiement de MariaDB sur le serveur principal Debian.

Configuration : Activation des logs binaires (log-bin) dans le fichier my.cnf et définition d'un identifiant unique (server-id).

2. Sécurisation des Accès

Utilisateur dédié : Création d'un compte avec des droits restreints au privilège REPLICATION SLAVE uniquement.

Principe du moindre privilège : Isolation des droits pour limiter les risques de sécurité en cas de compromission.

3. Initialisation du Slave

Export des données : Utilisation de mysqldump pour exporter l'intégralité de la base du Master.

Import sur le Slave : Restauration des données sur le serveur secondaire pour garantir une base commune de départ.

4. Lancement de la Réplication

Configuration Slave : Pointage vers l'adresse IP du Master avec les coordonnées du log binaire (MASTER_LOG_FILE et MASTER_LOG_POS).

Démarrage : Activation de la réplication avec START SLAVE et vérification de l'état de synchronisation.

5. Tests et Validation (Recettage)

Contrôle d'état : Commande SHOW SLAVE STATUS\G pour vérifier que les processus IO et SQL sont actifs.

Tests de cohérence : INSERT, UPDATE et DELETE sur le Master avec vérification instantanée de la répercussion sur le Slave.

6. Simulation de Sinistre (Failover)

Arrêt forcé : Simulation de panne en arrêtant le service MariaDB sur le Master.

Promotion du Slave : Exécution de STOP SLAVE; RESET MASTER; pour transformer le Slave en nouveau Master opérationnel.

Difficultés rencontrées

Décalage de Position Binlog

Difficulté : Erreur de synchronisation due à une mauvaise récupération des coordonnées MASTER_LOG_FILE et MASTER_LOG_POS.

Solution : Utilisation systématique de FLUSH TABLES WITH READ LOCK avant l'export pour figer l'état de la base et récupérer les bonnes coordonnées via SHOW MASTER STATUS.

Compétence : Gérer le patrimoine informatique

Erreur de Connexion Réseau

Difficulté : Le Slave ne parvenait pas à se connecter au Master (erreur "Connection refused").

Solution : Vérification que MariaDB écoute sur toutes les interfaces (bind-address = 0.0.0.0) et ouverture du port 3306 dans le pare-feu.

Compétence : Mettre à disposition un service

Données Désynchronisées

Difficulté : Après une coupure réseau, le Slave affichait un retard important (Seconds_Behind_Master élevé).

Solution : Analyse des logs et vérification de la bande passante réseau. Le Slave a rattrapé son retard automatiquement une fois la connexion rétablie.

Compétence : Répondre aux incidents

Compétences E5 Mobilisées

✔

Gérer le patrimoine informatique (Patrimoine) Vérifier les conditions de la continuité d'un service informatique - Mise en place d'une architecture redondante pour garantir l'accès permanent aux données.

✔

Gérer le patrimoine informatique (Patrimoine) Gérer des sauvegardes - Utilisation de la réplication comme mécanisme de "sauvegarde à chaud" (copie temps réel des données).

✔

Répondre aux incidents (Incidents) Traiter des demandes concernant les services applicatifs - Mise en œuvre d'une procédure de rétablissement du service après un incident majeur.

✔

Mettre à disposition un service (Service) Réaliser les tests d'intégration et d'acceptation d'un service - Validation de la non-corruption des données lors de la bascule entre les nœuds.

Bilan Personnel et Compétences Acquises

Cette réalisation m'a permis de comprendre les mécanismes critiques de la persistance des données dans une infrastructure professionnelle.

Compétences Développées

Administration SGBD Linux : J'ai appris à configurer finement MariaDB, notamment les paramètres de réplication dans my.cnf et à gérer les problématiques de synchronisation réseau.
Analyse de risques : J'ai pris conscience que la sécurité des données ne repose pas uniquement sur les sauvegardes froides (backups), mais aussi sur la disponibilité immédiate via la redondance.
Procédures de reprise : Maîtrise des étapes de promotion d'un Slave en Master pour assurer la continuité d'activité.

Améliorations Possibles

Pour améliorer cette architecture :

Failover automatique : Utilisation d'un outil comme MaxScale ou un cluster Galera pour une gestion transparente du basculement sans intervention manuelle.
Réplication Multi-Master : Mise en place d'une réplication bidirectionnelle pour permettre l'écriture sur les deux nœuds.
Monitoring : Intégration d'alertes Zabbix ou Nagios pour surveiller l'état de la réplication en temps réel.

Réplication de Base de Données MariaDB (Master-Slave)