La réplication MariaDB copie des modifications entre serveurs. Elle peut contribuer à une architecture de reprise, mais elle ne fournit pas à elle seule la haute disponibilité : il faut également décider qui reçoit les écritures, détecter les pannes et maîtriser le basculement.
Ce que faisait le montage historique
Le montage d’origine associait deux VPS et une réplication dans les deux sens. Chaque serveur pouvait recevoir les changements de l’autre. Ce principe permet d’étudier la réplication bidirectionnelle ; il ne faut pas le confondre avec un cluster qui résout les conflits.
Les anciennes adresses, commandes d’installation et valeurs d’identification ne constituent pas une configuration à réutiliser. Pour une nouvelle installation, partez de la documentation de votre version de MariaDB et d’un schéma adapté à votre application.
Pourquoi l’actif-actif peut produire des conflits
Si deux applications modifient les mêmes données sur deux serveurs, leurs opérations peuvent être incompatibles. Des plages d’auto-incrément différentes réduisent certains conflits d’identifiants, mais ne règlent pas les mises à jour concurrentes ni toutes les contraintes d’unicité.
Une interruption réseau peut aussi laisser deux serveurs accepter des écritures indépendamment. Quand le réseau revient, rien ne garantit que la réplication réconciliera ces décisions. La documentation MariaDB souligne les limites des topologies de réplication sans résolution des conflits.
Définir le serveur autorisé à écrire
Pour une architecture primaire-secondaire, documentez le serveur qui reçoit les écritures et les permissions nécessaires. Le routage applicatif, les comptes, les contrôles de lecture seule et la procédure d’exploitation doivent être cohérents. Aucun de ces mécanismes ne doit être présumé sur la seule base d’une IP flottante.
Avant de promouvoir un secondaire, il faut isoler l’ancien primaire ou lui retirer effectivement la possibilité d’écrire. Cette étape de mise à l’écart évite que deux serveurs se comportent comme le primaire après une panne partielle.
Initialiser et surveiller la réplication
Le secondaire doit démarrer à partir d’une sauvegarde cohérente, avec les informations de réplication correspondant à cette sauvegarde. Le choix entre positions de journal et GTID dépend du déploiement. Ne reprenez pas des positions issues d’un exemple.
Sur une version qui prend en charge cette commande, l’état se consulte avec :
SHOW SLAVE STATUS\G
Contrôlez les threads de réception et d’application, les dernières erreurs, les positions et le retard. Un état actif ne prouve pas l’égalité de toutes les données. Les indicateurs de retard doivent être interprétés avec les erreurs et l’activité de l’application.
Construire une procédure de basculement
- Définir la perte de données et le délai de reprise acceptables.
- Détecter la panne sans confondre un problème réseau avec l’arrêt du serveur.
- Empêcher les écritures sur l’ancien primaire.
- Vérifier l’état du secondaire avant sa promotion.
- Basculer les connexions et tester l’application.
- Réintégrer l’ancien serveur à partir d’un état cohérent.
La réplication ne remplace pas les sauvegardes
Une suppression accidentelle ou une modification incorrecte peut être répliquée. Conservez des sauvegardes indépendantes, leur historique et des tests de restauration. Voir la règle de sauvegarde 3-2-1.
Pour un incident de base, commencez par les journaux et le diagnostic des tables MySQL ou MariaDB. Une commande de réparation ne remplace pas une analyse du moteur et de la panne.
Documentation
MariaDB : topologies de réplication ; MariaDB : référence de la réplication.
