ApsaraDB RDS:Optimiser la latence de réplication pour les transactions volumineuses

Fonctionnement

Latence de réplication pour les transactions volumineuses (schéma de gauche) : dans MySQL, le réplica ne commence à appliquer une transaction volumineuse qu'après sa validation sur l'instance principale. Le temps d'exécution de la transaction sur le réplica constitue donc la latence de réplication. Pendant cette période, les autres transactions validées sur l'instance principale ne peuvent pas être appliquées sur le réplica, ce qui retarde les mises à jour des données.

Optimisation de l'application en temps réel pour les transactions volumineuses (schéma de droite) : l'optimisation principale consiste à exécuter la transaction volumineuse simultanément sur le réplica et sur l'instance principale. Lorsque la transaction volumineuse est validée sur l'instance principale, elle l'est également sur le réplica. De même, si la transaction est annulée sur l'instance principale, elle l'est aussi sur le réplica.

Prérequis

Pour utiliser la fonctionnalité d'application en temps réel pour les transactions volumineuses, votre instance doit satisfaire à l'exigence suivante :

• Version du moteur de base de données : MySQL 8.0 avec une version mineure du moteur égale ou supérieure à 20260228. Si votre instance ne répond pas à cette exigence, vous pouvez mettre à niveau la version mineure du moteur ou mettre à niveau la version du moteur de base de données.

Procédure

1. Accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région où réside l'instance RDS. Localisez ensuite l'instance RDS et cliquez sur son ID.

2. Dans le volet de navigation de gauche, cliquez sur Parameters.

3. Sous l'onglet Editable Parameters, recherchez et configurez les paramètres suivants :

   1. Activer la fonctionnalité d'application en temps réel pour les transactions volumineuses :

      1. Définissez loose_binlog_realtime_apply_long_trx_enabled sur ON.

      2. Définissez loose_binlog_realtime_transmit_source_enabled sur ON.

      3. Définissez loose_binlog_realtime_transmit_replica_enabled sur ON.

   2. Autres paramètres requis :

      Parameter	Description	Recommended value
      loose_binlog_realtime_replica_long_transaction_limit_size	Spécifie le seuil de taille d'une transaction pour déclencher la réplication en temps réel. Lorsque les événements binlog générés par une transaction dépassent cette valeur, cette fonctionnalité est automatiquement activée.	64 MB
      loose_binlog_realtime_enable_log_messag	Indique s'il faut écrire les journaux de réplication en temps réel dans le journal des erreurs. Nous vous recommandons d'activer ce paramètre.	ON
      loose_binlog_realtime_apply_workers	Contrôle le nombre de threads Brr Worker pour la réplication en temps réel.	8

4. Cliquez sur OK, puis sur Submit Parameters. Dans la boîte de dialogue qui s'affiche, choisissez le moment d'application des modifications. Les modifications de paramètres prennent effet immédiatement sans nécessiter de redémarrage de l'instance.

Résultats de l'optimisation

L'exemple suivant illustre l'effet de cette fonctionnalité sur une transaction d'importation de données impliquant 5 millions de lignes sur l'instance principale :

• Avant l'optimisation : la transaction s'exécute d'abord sur l'instance principale. Après sa validation, elle est appliquée sur le réplica. La latence de réplication est égale au temps d'exécution de la transaction.

• Après l'optimisation : la transaction s'exécute simultanément sur l'instance principale et sur le réplica, ce qui élimine la latence de réplication.