Pendant les heures de pointe, de nombreuses charges de travail mettent à jour les bases de données avec un niveau de concurrence élevé. Si le débit des transactions (TPS) sur l'instance principale dépasse le débit des threads d'E/S et SQL sur une instance réplica, une latence de réplication peut survenir. Pour résoudre ce problème, ApsaraDB RDS for MySQL optimise la logique d'attente de verrou entre les threads d'E/S, SQL et de travail, et réduit le nombre d'attentes de verrou. Cette optimisation élimine la latence de réplication pour les charges de travail composées de petites transactions à forte concurrence.
Présentation
Latence de réplication
Latence de réplication : Pendant les heures de pointe, de nombreuses charges de travail mettent à jour les bases de données avec un niveau de concurrence élevé. Si l'instance principale applique les transactions avec une concurrence plus élevée que l'instance réplica, le débit des transactions du réplica peut prendre du retard, entraînant une latence de réplication. Même si vous augmentez le nombre de threads de travail ou activez la fonctionnalité Writeset, la concurrence d'application du réplica peut rester insuffisante car son thread d'E/S ou SQL atteint un goulot d'étranglement en termes de débit.
Goulots d'étranglement du débit des threads d'E/S et SQL : La réplication multithread de MySQL utilise trois types de threads : le thread d'E/S, le thread SQL et plusieurs threads de travail. Le thread d'E/S récupère les événements binlog depuis l'instance principale. Le thread SQL distribue ces événements binlog aux threads de travail. Les threads de travail appliquent ensuite les transactions en parallèle.
La coordination entre les threads d'E/S et SQL, ainsi qu'entre le thread SQL et les threads de travail, repose sur des opérations d'attente et de notification protégées par des verrous. Chaque événement binlog nécessite un tel cycle de verrouillage et de notification. Une seule transaction est constituée de plusieurs événements binlog. Par exemple, dans le script de test courant sysbench write_only, une transaction implique la mise à jour de deux lignes, l'insertion d'une ligne et la suppression d'une ligne, ce qui génère 11 événements binlog. En cas de forte concurrence, ces verrous deviennent fréquemment un goulot d'étranglement des performances, limitant le débit des threads d'E/S et SQL.
Lorsque le thread d'E/S ou SQL atteint un goulot d'étranglement en termes de débit, les threads de travail ne reçoivent pas rapidement les transactions à appliquer. Si la concurrence d'application des threads de travail sur l'instance réplica est inférieure à la concurrence de la charge de travail sur l'instance principale, une latence de réplication se produit.
Optimisation du lot de petites transactions
Pour optimiser la latence de réplication des petites transactions à forte concurrence, AliSQL introduit une optimisation par lot de petites transactions. Cette optimisation regroupe les multiples événements binlog d'une petite transaction en un seul cycle de verrouillage et de notification pour les threads d'E/S et SQL. Cette approche réduit considérablement le nombre d'opérations de verrouillage, augmentant ainsi le débit des threads d'E/S et SQL.
Prérequis
Pour utiliser cette optimisation, votre instance doit répondre à l'exigence suivante :
Version du moteur de base de données : Votre instance doit exécuter ApsaraDB RDS for 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
Activez cette fonctionnalité en configurant un paramètre global sur vos instances principales ou en lecture seule :
Accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région où réside l'instance RDS. Recherchez ensuite l'instance RDS et cliquez sur l'ID de l'instance.
Dans le volet de navigation de gauche, cliquez sur Parameter settings.
-
Dans l'onglet Modifiable parameters, recherchez le paramètre
loose_replica_package_transaction_limit_sizeet configurez sa valeur.Description du paramètre : Une valeur de 0 désactive cette fonctionnalité. Lorsque la valeur est supérieure à 0, les transactions dont la taille binlog est inférieure à cette valeur sont éligibles à cette optimisation.
Valeurs valides : de 0 à 1 Mo.
Valeur recommandée : 1 Mo.
Cliquez sur OK, puis sur Submit parameters. Dans la boîte de dialogue, sélectionnez une Effective period. La modification du paramètre prend effet immédiatement et ne nécessite pas de redémarrage de l'instance.
Résultats de l'optimisation
Nous avons exécuté le script sysbench write_only sur l'instance principale avec 128 threads concurrents (80 000 transactions par seconde ou TPS) pour simuler une charge d'écriture de pointe de 60 secondes. Le test a donné les résultats suivants :
Avant l'optimisation : La latence de réplication sur l'instance réplica augmentait continuellement et le débit était très faible.
Après l'optimisation : L'instance réplica n'a présenté aucune latence de réplication et son débit a presque doublé.
