GTID ou Identifiant de transaction global a été introduit dans MySQL 5.6.5. Un GTID est un identifiant unique au monde attribué à toutes les transactions exécutées sur un serveur d'hébergement MySQL compatible GTID. Les GTID sont une combinaison de l'UUID du serveur sur lequel une transaction particulière a été validée et du numéro de séquence de cette transaction sur ce serveur particulier. Cela rend le GTID unique au monde.

Réplication MySQL

La réplication basée sur GTID est beaucoup plus flexible que l'ancienne réplication basée sur binlog. Dans une configuration basée sur GTID, l'esclave n'a pas besoin d'un fichier binlog maître et d'une position pour démarrer la réplication. En savoir plus sur la réplication basée sur GTID. Dans cet article de blog, nous discuterons de certains problèmes courants de réplication MySQL causés lors du déploiement d'un jeu de répliques basé sur GTID.

Transactions errantes sont des transactions appliquées à un ou plusieurs esclaves qui n'ont pas besoin d'être répliquées sur d'autres nœuds. Il peut s'agir de correctifs intermittents appliqués sur l'esclave ou d'écritures accidentelles sur l'esclave par une application.

Le problème avec ces transactions errantes survient lorsque l'esclave qui contient une transaction errante est promu au rang de maître. Dans le cas d'une réplication basée sur GTID, cela poserait un problème. Le nouveau maître réalise maintenant que les esclaves n'ont pas exécuté la transaction erronée. L'une des deux choses suivantes peut se produire :

(1) La transaction errante est toujours présente dans le binlog du maître et il l'enverra aux esclaves, cela peut corrompre les données ou provoquer une erreur.
(2) La transaction n'est pas présente dans le binlog, et donc ne peut pas être envoyé à l'esclave, ce qui provoque une erreur de réplication.

Prévention

Les transactions errantes peuvent activement être empêchées en suivant ces étapes. Si vous devez appliquer un correctif à un esclave, une façon d'atténuer les transactions errantes consiste à désactiver temporairement la journalisation binaire sur l'esclave. Exécuter sql_bin_log =0 avant d'exécuter la requête errante devrait faire l'affaire. Vous pouvez ensuite activer binlog en exécutant sql_bin_log =1. Pour empêcher toute application d'écrire sur les esclaves, la lecture seule doit être activée sur un serveur lorsqu'il est configuré en tant qu'esclave.

Détection

Il est facile de détecter une transaction errante dans un jeu de répliques MySQL basé sur GTID. MySQL stocke tous les GTID exécutés dans sa table Schéma de performance/Schéma d'information en fonction de la version de MySQL que vous utilisez. Prendre les GTID exécutés par l'esclave actuel et les soustraire des GTID exécutés sur le maître actuel devrait vous donner toutes les transactions errantes sur cet esclave particulier. Des utilitaires tels que mysqlfailover ou mysqlrpladmin peuvent également aider à détecter les transactions errantes.

Solution

Une fois qu'une transaction errante a été détectée, il existe deux façons de corriger les erreurs de réplication causées après un basculement. Une façon consiste à supprimer le GTID de la transaction errante de l'historique d'exécution du GTID esclave. De cette façon, lorsque l'esclave est promu maître, la transaction errante ne serait pas répliquée sur tous les nœuds. Une autre façon de gérer les transactions errantes est de dire à tous les autres esclaves de sauter la transaction errante. Cela inclurait l'insertion d'une transaction vide avec le même GTID que la transaction errante à tous les autres nœuds du jeu de répliques. Cela fera croire à tous les autres nœuds qu'ils ont déjà appliqué cette transaction et qu'ils doivent donc l'ignorer. MySQL dispose d'un utilitaire appelé Mysqlslavetrx dédié à cela. Cet utilitaire peut être utilisé pour insérer des transactions vides avec le GTID donné. L'ajout de transactions vides peut également avoir d'autres utilisations, comme indiqué ici.