Dans une configuration maître-esclave MySQL 5.7 qui utilise le paramètre de réplication semi-synchrone par défaut pour rpl_semi_sync_master_wait_point , une panne du maître et un basculement vers l'esclave sont considérés comme sans perte. Cependant, lorsque le maître en panne revient, vous pouvez constater qu'il contient des transactions qui ne sont pas présentes dans le maître actuel (qui était auparavant un esclave). Ce comportement peut être déroutant, étant donné que la réplication semi-synchrone est censée être sans perte, mais c'est en fait un comportement attendu dans MySQL. Pourquoi exactement cela se produit est expliqué en détail dans le blog de Jean-François Gagné (JF).
Dans un tel scénario, la documentation MySQL recommande que le maître en panne soit supprimé et ne soit pas redémarré. Cependant, se débarrasser d'un serveur comme celui-ci est coûteux et inefficace. Dans cet article de blog, nous expliquerons une approche pour détecter et corriger les transactions sur le serveur maître MySQL en panne dans une configuration de réplication semi-synchrone, et comment le ré-asservir dans votre configuration maître-esclave.
Pourquoi est-il important de détecter les transactions supplémentaires sur le maître récupéré ?
Les transactions supplémentaires sur le maître récupéré peuvent se manifester de deux manières :
1. Échecs de réplication MySQL lorsque le maître récupéré est réasservi
Cela se produit généralement lorsque vous avez une clé primaire à incrémentation automatique. Lorsque le nouveau maître MySQL insère une ligne dans une telle table, la réplication échouera car la clé existe déjà sur l'esclave.
Un autre scénario est lorsque votre application tente à nouveau la transaction qui a échoué lors de la panne principale. Sur le maître MySQL récupéré (qui est maintenant un esclave), cette transaction existerait réellement, et encore une fois, entraînerait une erreur de réplication.
Typiquement, l'erreur de réplication MySQL ressemblerait à ceci :
| [ERREUR] SQL esclave pour le canal '' :le travailleur 5 n'a pas pu exécuter la transaction 'fd1ba8f0-cbee-11e8- b27f-000d3a0df42d:5938858' dans le journal principal mysql-bin.000030, end_log_pos 10262184 ; Erreur 'Entrée en double '5018' pour la clé 'PRIMARY'' lors de la requête. Base de données par défaut :'test'. Requête :'insert into test values(5018,2019,'item100')', Error_code :1062 |
2. Incohérence silencieuse dans les données entre le nouveau maître et l'esclave MySQL (maître récupéré)
Dans les cas où l'application ne réessaye pas la transaction ayant échoué et qu'il n'y a pas de collisions de clé primaire à l'avenir, une erreur de réplication peut ne pas se produire. Par conséquent, l'incohérence des données peut ne pas être détectée.
Dans les deux cas ci-dessus, la haute disponibilité ou l'intégrité des données de votre configuration MySQL est affectée, c'est pourquoi il est si important de détecter cette condition le plus tôt possible.
Comment détecter les transactions supplémentaires sur le maître MySQL récupéré
Nous pouvons détecter s'il y a des transactions supplémentaires sur le maître récupéré à l'aide de la fonction MySQL GTID (identifiant de transaction global) :
GTID_SUBSET(set1 ,set2 ) :étant donné deux ensembles d'ID de transaction globaux set1 et set2 , renvoie true si tous les GTID de set1 sont également dans set2 . Renvoie faux sinon.
Prenons un exemple pour comprendre cela.
- GTID défini sur le maître récupéré dont l'UUID est : 54a63bc3-d01d-11e7-bf52-000d3af93e52 ' est :
- '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9700,57956099-d01d-11e7-80bc-000d3af97c09:1-810'
- L'ensemble GTID du nouveau maître dont l'UUID est : 57956099-d01d-11e7-80bc-000d3af97c09 ' est :
- '54a63bc3-d01d-11e7-bf52-000d3af93e52:1-9690,57956099-d01d-11e7-80bc-000d3af97c09:1-870'
Maintenant, si nous appelons la fonction GTID_SUBSET comme GTID_SUBSET (ensemble GTID du maître récupéré, ensemble GTID du nouveau maître) , la valeur de retour sera vraie, uniquement si le maître récupéré n'a pas de transactions supplémentaires. Dans notre exemple ci-dessus, puisque le maître récupéré a des transactions supplémentaires 9691 à 9700, le résultat de la requête ci-dessus est faux.
Ré-asservir un serveur maître #MySQL en panne dans une configuration de réplication semi-synchroneClick To TweetComment ré-asservir le maître MySQL récupéré qui a des transactions supplémentaires
En fonction de l'étape ci-dessus, il est possible de savoir si le maître récupéré a des transactions supplémentaires et quelles transactions utilisent la fonction GTID :GTID_SUBTRACT(GTID set of maître récupéré, ensemble GTID du nouveau maître).
Il est également possible d'extraire ces transactions supplémentaires des journaux binaires et de les enregistrer. Il peut être utile pour votre équipe commerciale d'examiner ultérieurement ces transactions afin de s'assurer que nous ne perdons pas par inadvertance des informations commerciales importantes, même si elles n'ont pas été validées. Une fois cela fait, nous avons besoin d'un moyen de se débarrasser de ces transactions supplémentaires afin que le maître récupéré puisse être réasservi sans problème.
L'une des façons les plus simples de procéder consiste à prendre un instantané de sauvegarde sur le maître actuel et à restaurer les données sur votre esclave actuel. N'oubliez pas que vous devez conserver l'UUID de ce serveur comme avant. Après avoir restauré les données, le serveur peut être réasservi et il commencera la réplication à partir du point de l'instantané restauré. Vous aurez bientôt à nouveau un esclave en bonne santé !
Les étapes ci-dessus sont très fastidieuses si vous devez les exécuter manuellement, mais le service d'hébergement MySQL entièrement géré de ScaleGrid peut automatiser l'ensemble du processus pour vous sans aucune intervention requise. Voici comment cela fonctionne :
Si votre maître actuel tombe en panne, ScaleGrid automatise le processus de basculement et promeut un esclave approprié en tant que nouveau maître. L'ancien maître est alors récupéré, et nous détectons automatiquement s'il y a des transactions supplémentaires dessus. Si vous en trouvez, le déploiement MySQL est mis dans un état dégradé et nous utilisons des outils automatisés pour extraire et enregistrer les transactions supplémentaires pour votre examen. Notre équipe d'assistance peut alors restaurer l'ancien maître dans un bon état et le remettre en esclave dans votre configuration maître-esclave afin que vous ayez un déploiement sain !
Vous voulez essayer ? Démarrez un essai gratuit de 30 jours pour explorer toutes les fonctionnalités de gestion de base de données MySQL sur ScaleGrid.
