Réplication MySQL : exploitation courante et scénarios de panne (8.0 / 8.4)

Runbook d'exploitation courante et de reprise après panne pour une topologie source + replica existante (async / semi-sync, GTID ou position binlog) : contrôle de santé et du retard, switchover planifié, failover, réintégration de l'ancienne source, reconstruction d'un replica (clone / XtraBackup / mysqldump), GTID errants, erreurs 1062/1032, récupération de données depuis un replica retardé, déplacement d'un replica et purge des binlogs. Chaque scénario suit le schéma diagnostic → filet de sécurité → application → vérification → suites. Ce n'est pas un guide d'installation : pour mettre en place la réplication la première fois, ouvrez le guide «Réplication GTID MySQL», pour InnoDB Cluster (Group Replication) le guide «Exploitation d'InnoDB Cluster».

Topologie: 1 source + 1..5 replicas (async / semi-sync)

Scénarios

• Contrôle de l'état et du retard (la réplication est-elle saine ?) — Lecture seule : threads IO/SQL, dernières erreurs, retard réel, état semi-sync et contrôle des GTID errants ; rien n'est modifié, aucune interruption. Si vous ne savez pas quoi faire, commencez ici : la dernière étape vous oriente vers le bon scénario selon la sortie.
• Switchover planifié (transférer le rôle de source à un replica) — La source et les replicas sont sains ; vous transférez de façon planifiée le rôle de source à un replica pour une maintenance, un remplacement matériel ou une mise à niveau. Les écritures s'arrêtent quelques minutes, aucune donnée n'est perdue ; le retour arrière est le même scénario en sens inverse.
• Source perdue : failover vers le replica le plus avancé — La source est tombée ou injoignable et ne reviendra pas rapidement (thread IO Connecting sur les replicas, 2003/2013). Le replica le plus avancé devient la nouvelle source, les autres s'y connectent. Les écritures sont coupées jusqu'à l'ouverture de la nouvelle source ; en asynchrone, les dernières transactions de la source peuvent être perdues.
• Réintégrer l'ancienne source comme replica après un failover — Un failover a eu lieu et l'ancien serveur source est revenu. Il est d'abord fermé aux écritures et ses binlogs sont copiés, puis on recherche des transactions errantes ; s'il est propre, il devient directement replica, sinon il est reconstruit depuis la nouvelle source. Aucune interruption sur la nouvelle source.
• Reconstruire un replica de zéro (clone / XtraBackup / mysqldump) — Les binlogs dont le replica a besoin ont été purgés sur la source (1236), ses données ont divergé de la source, les erreurs 1062/1032 reviennent sans cesse ou le disque du replica a été perdu. Toutes les données du replica sont remplacées par une copie de la source ; la source reste en ligne, le replica cible est indisponible pendant ce temps.
• GTID errant : le replica contient des transactions absentes de la source — Le replica contient des transactions écrites directement sur lui (pendant que super_read_only était désactivé) ou héritées d'une ancienne source ; lors d'un failover, ces transactions se propagent aux autres replicas ou arrêtent la réplication avec 1236. Solution : transaction vide, application sur la source ou reconstruction. Aucune interruption.
• Réplication arrêtée : 1062 Duplicate entry / 1032 Can't find record — Le thread SQL s'est arrêté sur une erreur de données (Replica_SQL_Running: No, Last_SQL_Errno 1062/1032/1146/1677…). On remet d'abord la ligne dans son état sur la source ; si ce n'est pas possible, en dernier recours, une seule transaction est ignorée. Seul ce replica est concerné : il prend du retard et les applications qui le lisent voient des données périmées.
• Replica retardé (SOURCE_DELAY) : le mettre en place ou récupérer des données supprimées — Vous voulez maintenir volontairement un replica N secondes en retard (définir / supprimer le retard), ou récupérer depuis le replica retardé des données supprimées/modifiées par erreur (DROP, DELETE/UPDATE sans WHERE) avant qu'elles n'y soient appliquées. La source reste en ligne.
• Déplacer un replica vers une autre source (chaînage / reconnexion) — Vous voulez rattacher un replica sous un autre replica (chaîne / replica intermédiaire) ou de nouveau à la source ; aucune donnée n'est copiée, seule la connexion change. Le replica déplacé s'arrête quelques secondes.
• Purge des binlogs et durée de conservation (disque qui se remplit) — Les binlogs remplissent le disque ou vous voulez régler la durée de conservation ; la purge se fait sans supprimer les fichiers dont les replicas et la PITR ont encore besoin. Aucune interruption.

Avant de commencer

• MySQL …… (8.0.26 et ultérieures)… dans la même version mineure sur tous les serveurs…, gtid_mode = ON et enforce_gtid_consistency = ON…, binlog activé… ; le root du système d'exploitation peut se connecter avec mysql sans mot de passe (auth_socket ou ~/.mylogin.cnf). La topologie a été mise en place avec le guide d'installation de la réplication ou de façon équivalente.
• Rôles vérifiés conformes aux saisies : … (…)… est l'ancienne source perdue… est la source actuelle (read_only = 0, aucune configuration de replica)…, les serveurs de la liste sont des replicas.… Promu source lors du failover : … (…).…
• Le mot de passe du compte … est connu. Le compte existe pour l'IP de chaque serveur ('…'@'<ip>', REQUIRE SSL) ; les étapes l'utilisent pour lire des valeurs comme l'ensemble GTID sur les autres serveurs et pour la connexion de réplication lors d'un changement de rôle. Le mot de passe ne contient ni ', ni ", ni \.
• Les serveurs se joignent mutuellement sur le port ….
• Les deux plugins semi-sync sont installés et ACTIVE sur tous les serveurs : rpl_semi_sync_source (semisync_source.so) et rpl_semi_sync_replica (semisync_replica.so) ; lors d'un changement de rôle, les deux côtés sont activés ou désactivés sur chaque serveur. Si ce sont les anciens rpl_semi_sync_master / rpl_semi_sync_slave (avant 8.0.26, dépréciés en 8.4) qui sont chargés, les variables rpl_semi_sync_source_enabled / rpl_semi_sync_replica_enabled utilisées dans les étapes n'existent pas : supprimez d'abord l'ancien plugin avec UNINSTALL PLUGIN puis installez le nouveau (les deux ne peuvent pas être chargés sur le même serveur ; INSTALL PLUGIN est refusé sur un serveur en lecture seule, super_read_only est donc désactivé temporairement).
• Sur le replica qui devient nouvelle source / serveur intermédiaire, log_bin = ON et log_replica_updates = ON (valeur par défaut en 8.x) ; sinon son binlog ne contient pas les transactions venant de la source et les autres replicas ne peuvent pas s'y connecter.
• Un accès SSH root (par clé) existe entre les serveurs concernés pour le transfert de fichiers… : … → ……. Sinon, transférez les fichiers avec la méthode approuvée par votre organisation ; les étapes indiquent les chemins des fichiers.
• Percona XtraBackup de la même version majeure que MySQL est installé sur le donneur (…) et la cible (…) ; le compte de sauvegarde bkpuser (auth_socket) existe sur le donneur — les deux premières phases du guide XtraBackup.
• L'approbation du changement et un canal de communication sont en place (équipe applicative, fenêtre de maintenance). Pour un changement de rôle, on sait qui modifie le point d'écriture de l'application (VIP, DNS, ProxySQL / HAProxy / Router) et comment.

Phases du guide

• État : source, replicas et retard (lecture seule) — Afficher le rôle de la source, sa position binlog et les replicas connectés · Afficher l'état des threads, les erreurs et le retard des replicas · Mesurer le retard réel et la file d'application dans performance_schema · Contrôle des GTID errants (le replica contient-il des transactions absentes de la source ?) · Interpréter le résultat et choisir le bon scénario
• 1. Diagnostic : prêt pour le switchover ? — Contrôler la source et les replicas connectés · Vérifier que le replica candidat convient · Vérifier que tous les replicas sont sains
• 2. Filet de sécurité — Enregistrer l'état actuel sur tous les serveurs
• 3. Application : transférer le rôle — Arrêter les écritures de l'application · Fermer la source aux écritures et relever la dernière position · Attendre que les replicas rattrapent la source · Promouvoir le candidat en source (promote) · Faire de l'ancienne source un replica de la nouvelle source · Connecter les autres replicas à la nouvelle source (…) …
• 4. Vérification — Faire une écriture de test sur la nouvelle source · Contrôler la réplication et la ligne de test sur tous les serveurs
• 5. Suites — Supprimer la base de test et mettre à jour l'exploitation
• 1. Diagnostic : la source est-elle vraiment perdue, et quel replica est le plus avancé ? — Tenter une dernière fois de joindre la source (depuis le replica candidat) · Isoler l'ancienne source (fencing) · Attendre sur chaque replica l'application des transactions du relay log · Déterminer le replica le plus avancé · Déterminer le replica le plus avancé (par position)
• 2. Filet de sécurité — Enregistrer l'état actuel sur les replicas
• 3. Application : failover — Promouvoir le candidat en source (promote) · Connecter les autres replicas à la nouvelle source (…) · Ouvrir les écritures sur la nouvelle source · Rediriger l'application vers la nouvelle source
• 4. Vérification — Faire une écriture de test sur la nouvelle source · Contrôler la réplication et la ligne de test sur les replicas
• 5. Suites — Planifier le traitement des transactions perdues, des sauvegardes et de l'ancienne source
• 1. Diagnostic : l'ancienne source est-elle propre ? — Afficher l'état de l'ancienne source · Trouver les transactions errantes (comparer avec la nouvelle source) · Décision de réintégration en réplication par position
• 2. Filet de sécurité — Fermer immédiatement l'ancienne source aux écritures et enregistrer son état · Extraire les transactions errantes dans un fichier séparé
• 3. Application : connecter comme replica — Connecter l'ancienne source à la nouvelle source
• 4. Vérification — Vérifier que l'ancienne source fonctionne comme replica
• 5. Suites — Planifier la topologie et l'avenir de l'ancienne source
• 1. Diagnostic : quel est l'ensemble errant ? — Calculer l'ensemble des GTID errants
• 2. Filet de sécurité : sauvegarder le contenu des transactions errantes — Décoder les transactions errantes depuis le binlog et les sauvegarder
• 3. Application : injecter des transactions vides sur la source — Exécuter les GTID errants comme transactions vides sur la source
• 3. Application : appliquer les transactions errantes sur la source — Extraire les transactions errantes dans un fichier et le copier sur la source · Appliquer les transactions sur la source
• 4. Vérification — Vérifier qu'il ne reste aucun ensemble errant
• 5. Suites : éviter que cela se reproduise — Trouver la cause racine et protéger les replicas
• 1. Diagnostic : quelle transaction, quelle ligne ? — Afficher l'erreur et la transaction en échec · Décoder depuis le relay log les lignes de la transaction en échec · Comparer la ligne sur la source et sur le replica
• 2. Filet de sécurité — Enregistrer l'état du replica et l'état actuel de la table
• 3. Application : corriger la ligne sur le replica — Préparer le SQL de correction · Appliquer la correction sans écrire dans le binlog et démarrer la réplication
• 3. Application : ignorer la transaction en échec (dernier recours) — Ignorer uniquement la transaction en échec
• 4. Vérification — Comparer la ligne et le checksum de la table des deux côtés
• 5. Suites — Trouver la cause racine
• 1. Diagnostic — Afficher le paramètre de retard actuel du replica
• 2. Filet de sécurité — Enregistrer l'état du replica