Dans un environnement de réplication semi-synchrone MySQL, la validation d'une transaction volumineuse déclenche souvent un délai d'expiration en raison de la transmission prolongée du journal binaire (Binlog). Cette situation dégrade la réplication semi-synchrone en réplication asynchrone, ce qui réduit la fiabilité des données. Elle bloque également les transactions suivantes et provoque des fluctuations de performances. Pour résoudre ce problème, RDS for MySQL introduit la fonctionnalité de transmission en temps réel du journal binaire. Cette fonctionnalité diffuse le Binlog d'une transaction volumineuse vers l'instance réplique pendant que la transaction est toujours en cours d'exécution. Cela réduit le temps de synchronisation lors de la validation à quelques millisecondes, garantissant ainsi une haute fiabilité des données et des performances de service stables.
Présentation de la fonctionnalité
Contexte
MySQL natif utilise un canal unique pour transmettre le Binlog entre les instances principales et les instances répliques. Lorsque le Binlog d'une transaction volumineuse occupe ce canal, il bloque la transmission du Binlog pour toutes les transactions suivantes. Cela entraîne une accumulation de transactions en attente de validation sur l'instance principale, rendant l'instance temporairement inaccessible en écriture. Pour éviter une interruption de service prolongée, MySQL introduit le paramètre rpl_semi_sync_master_timeout. Si l'instance réplique ne confirme pas la réception du Binlog dans le délai imparti, la réplication semi-synchrone se dégrade en réplication asynchrone. Par conséquent, les transactions volumineuses peuvent provoquer deux problèmes principaux :
Fluctuations de performances : L'instance devient inaccessible en écriture pendant plusieurs secondes et de nombreuses demandes de validation sont enregistrées en tant que requêtes SQL lentes.
Fiabilité réduite : Le mode de réplication se dégrade, ce qui peut entraîner une perte de données dans les cas extrêmes.
Transmission en temps réel du journal binaire
Dans le modèle traditionnel, le Binlog d'une transaction est mis en mémoire tampon dans le cache Binlog sur l'instance principale pendant l'exécution. Il est écrit dans un fichier Binlog et envoyé à l'instance réplique uniquement lorsque la transaction est validée. La fonctionnalité de transmission en temps réel du journal binaire dans RDS for MySQL optimise ce processus. Pour toute transaction volumineuse dépassant un seuil défini, la fonctionnalité diffuse en continu les événements Binlog générés depuis le cache Binlog vers l'instance réplique. Les événements sont stockés temporairement dans un cache Relay Log dédié. Lorsque la transaction est validée sur l'instance principale, seule une commande de validation finale est envoyée. L'instance réplique peut alors écrire immédiatement les données mises en cache dans son fichier Relay Log et renvoyer un accusé de réception. Cette conception par flux réduit le temps de transmission du Binlog lors de la validation de quelques secondes à quelques millisecondes, éliminant ainsi efficacement les goulots d'étranglement de transmission.
Principe technique : Conception du cache Relay Log
Pour stocker temporairement les événements Binlog diffusés sur l'instance réplique, RDS for MySQL crée un cache Relay Log dédié pour chaque transaction volumineuse. Avant d'écrire les données, le système réserve de l'espace au début du cache pour y insérer ultérieurement l'en-tête de l'événement Relay Log. Cela permet une conversion rapide du cache vers le fichier Relay Log. Le système gère intelligemment les cas où l'espace réservé est insuffisant ou excessif, soit en revenant à la logique d'origine, soit en ajoutant un événement vide (Empty Event), garantissant ainsi la robustesse du mécanisme.
Applicabilité
Cette fonctionnalité nécessite l'une des versions de base de données suivantes :
MySQL 8.4
MySQL 8.0 avec la version mineure du moteur 20250531 ou ultérieure
Instructions
Activez cette fonctionnalité en définissant les paramètres globaux suivants sur les instances principales et répliques. Les modifications de paramètres prennent effet immédiatement sans nécessiter de redémarrage de l'instance.
-
Pour activer la fonctionnalité :
Sur l'instance principale :
loose_binlog_realtime_transmit_source_enabled=ONSur l'instance réplique :
loose_binlog_realtime_transmit_replica_enabled=ON
-
Paramètre principal :
loose_binlog_realtime_transmit_long_transaction_limit_sizeObjectif : Spécifie le seuil de taille d'une transaction qui déclenche la transmission en temps réel. Lorsque le Binlog généré par une transaction dépasse cette taille, la fonctionnalité s'active automatiquement.
Valeur par défaut : 128 Mo.
Avantages
Nous avons simulé un scénario à charge élevée en exécutant une transaction volumineuse de 2 Go sur une instance avec réplication semi-synchrone. Les résultats des tests sont présentés dans la figure suivante :
Avant l'optimisation (MySQL natif) : Après la validation de la transaction volumineuse, le nombre de requêtes par seconde (QPS) de l'instance tombe à zéro, indiquant de graves fluctuations de performances. Par la suite, le système passe en mode asynchrone en raison d'un délai d'expiration semi-synchrone. Bien que les performances se rétablissent, la fiabilité des données est compromise.
Après l'optimisation (RDS for MySQL) : Avec la transmission en temps réel du journal binaire activée, le QPS de l'instance reste stable même lors de la validation de la transaction volumineuse. Cela empêche efficacement les fluctuations de performances et la dégradation du mode de réplication.
