Réplication MySQL après une coupure VPN : lisez d’abord les deux étapes

La supervision de la réplication passe au rouge quand le VPN tombe, et le réflexe est de réinitialiser une position. Ce réflexe est précisément ce qui transforme une coupure réseau en problème de données. Un chemin tombé ne dit rien de ce que le réplica a reçu ou appliqué, et ce sont deux étapes avec deux états. Lisez-les séparément avant de changer quoi que ce soit.

Deux étapes, deux réponses distinctes

Un réplica asynchrone classique fait deux travaux. Le récepteur se connecte à la source, tire les événements et les écrit localement dans le journal de relais. L’applicateur lit ce journal et exécute les événements sur le réplica. Quand le chemin se rompt, le récepteur s’arrête immédiatement tandis que l’applicateur continue de traiter le retard déjà présent sur le disque. Une coupure produit donc deux questions différentes : la connexion est-elle revenue et le travail accumulé a-t-il été appliqué ? Les traiter comme une seule question moyenne deux états en une réponse trompeuse.

Que le récepteur se rétablisse vous dit que le chemin est opérationnel. Cela ne dit rien du retard de l’applicateur, ni s’il a rencontré une erreur pendant la déconnexion.

Lisez le canal avec la bonne instruction

Sur MySQL 8.4, SHOW REPLICA STATUS renvoie une ligne par canal configuré, lisez donc la ligne du canal visé plutôt que la première de la liste. Replica_IO_Running distingue un récepteur connecté d’un récepteur en cours de connexion ou arrêté, et Replica_SQL_Running décrit l’applicateur. Lisez les colonnes d’erreur à côté, car un récepteur qui se reconnecte et échoue aussitôt laisse un message qu’aucun indicateur d’état n’affichera. Les versions plus anciennes utilisent d’autres noms de colonnes, ne traduisez donc pas une ancienne recette en renommant seulement les commandes.

Vérifiez aussi l’identité de la source et les filtres configurés. Un réplica pointé vers la mauvaise source, ou filtré plus étroitement que vous ne le pensez, signale une bonne santé tout en répliquant autre chose que ce que vous attendez.

Pourquoi un retard nul peut mentir

La valeur de retard compare l’horodatage du dernier événement appliqué à l’heure actuelle. Quand le récepteur est arrêté depuis une heure, l’applicateur peut traiter le retard et atteindre la fin de ce qu’il a reçu, et le chiffre tombe alors à zéro alors même que le réplica a une heure de retard sur la source. La métrique mesure la file de l’applicateur, pas l’actualité du réplica.

Comparez plutôt les transactions exécutées à ce dont la source dispose. Cette comparaison survit à un récepteur bloqué.

La rétention fixe la vraie fenêtre de reprise

Rattraper exige que la source conserve encore les transactions dont le réplica a besoin. Une fois celles-ci purgées, le réplica ne peut plus les récupérer, et aucune reconnexion n’y changera rien.

Avec l’auto-positionnement GTID, l’échec est explicite : le réplica demande un historique que la source ne conserve plus et refuse de continuer. Les options sont alors de récupérer les événements manquants auprès d’une source qui les a encore, ou de reconstruire depuis une sauvegarde et de la laisser rattraper. Sauter l’écart n’est pas rattraper, et cela laisse un réplica dont les données sont discrètement incomplètes. Planifiez la fenêtre en comparant la durée d’indisponibilité attendue à la rétention du journal binaire sur la source et au rythme de changement, car ces trois chiffres décident si une coupure est récupérable ou non.

Vérifiez le rattrapage, pas la couleur d’un indicateur

Rétablissez le chemin, y compris la résolution de noms et la sécurité du transport, puis observez si le canal existant se reconnecte selon sa propre politique. Accordez-lui un intervalle défini avant d’intervenir et relevez la progression de réception et d’application aux deux extrémités de cet intervalle. Un canal qui redémarre et un canal à jour sont deux constats différents.

Confirmez que l’applicateur a atteint la position actuelle de la source, et pas seulement la fin de l’ancien retard. Vérifiez qu’aucune erreur n’attend dans l’applicateur, car un seul événement en échec arrête la progression tandis que le récepteur continue de signaler la connexion. Relevez ensuite les preuves : nom du canal, les deux états d’étape, la position exécutée et l’heure. Un indicateur vert est une affirmation ; la position est un fait.