ApsaraDB RDS:Optimize large transaction commits

Fonctionnalités

Les écritures dans le journal binaire étant sérielles, une transaction volumineuse écrit lentement ses événements et bloque la validation des autres transactions. Cette fonctionnalité optimise le mécanisme d'écriture du journal binaire pour les validations de transactions volumineuses, rendant la vitesse de validation indépendante du nombre d'événements. Elle résout les problèmes courants suivants :

• Les transactions extrêmement volumineuses bloquent l'instance et empêchent la validation des autres transactions.

• Les transactions volumineuses entraînent une consommation élevée d'E/S, ce qui peut épuiser les ressources et ralentir d'autres opérations, telles que les requêtes.

• Les transactions volumineuses ralentissent l'exécution des petites transactions, provoquant une augmentation des connexions actives et des fluctuations de performances. Dans les cas graves, cela peut déclencher une défaillance en cascade et rendre l'instance indisponible.

• L'exécution fréquente de transactions volumineuses provoque une instabilité durable des performances de votre charge de travail.

Prérequis

L'instance doit répondre à l'une des exigences de version suivantes :

• MySQL 8.4

• MySQL 8.0 avec une version mineure du moteur 20240731 ou ultérieure.

• MySQL 5.7 avec une version mineure du moteur 20240731 ou ultérieure.

  Remarque

  Sur la page Basic Information, vérifiez la section Configuration Information pour le bouton Upgrade minor engine version. Si le bouton est disponible, mettez à niveau votre instance. Si le bouton n'est pas disponible, votre instance utilise déjà la dernière version mineure du moteur. Pour plus d'informations, consultez Mettre à niveau la version mineure du moteur.

Utilisation

• Nouvelles instances : la fonctionnalité binlog cache free flush est activée par défaut.

• Instances existantes : définissez la variable système globale loose_binlog_cache_free_flush pour activer cette fonctionnalité. La modification prend effet immédiatement sans nécessiter de redémarrage de l'instance.

• Paramètre associé :

  loose_binlog_cache_free_flush_limit_size : après avoir activé la fonctionnalité binlog cache free flush, si le journal binaire généré par une transaction dépasse la valeur de ce paramètre, le fichier temporaire du cache du journal binaire est promu en fichier de journal binaire lors de la validation. Valeur par défaut : 256 Mo. Plage de valeurs : 20971520 à 18446744073709551615 (unité : octets).

Analyse du problème

Lorsqu'une instance MySQL exécute une transaction volumineuse, le journal des requêtes lentes peut enregistrer des retards inhabituels pour des instructions censées s'exécuter rapidement, telles que COMMIT.

Le tableau d'analyse des performances SQL affiche les modèles SQL lents suivants et leurs métriques clés (base de données : sbtest) :

• COMMIT ? : exécuté 2 104 fois, durée moyenne 1,6375 s

• UPDATE t_large SET c=c+? : exécuté 989 fois, durée moyenne 4,3019 s, durée maximale 57,108 s, attente de verrou moyenne 1,7074 s

• DELETE FROM sbtest? WHERE id=? : exécuté 80 fois, durée moyenne 1,6977 s

• UPDATE sbtest? SET c=? WHERE id=? : exécuté 62 fois, durée moyenne 1,7872 s

La durée d'exécution maximale et le temps d'attente de verrou de UPDATE t_large sont nettement supérieurs à ceux des autres instructions SQL, indiquant que la transaction volumineuse constitue le goulot d'étranglement des performances.

Ce problème est causé par la contention des ressources dans le mécanisme d'écriture sérielle du journal binaire. Une transaction volumineuse dans un thread met beaucoup de temps à écrire son journal binaire, bloquant la validation des autres transactions et provoquant un retard global et sérialisé.

Lors d'un test sysbench oltp_write_only, après l'exécution d'une opération UPDATE volumineuse générant 512 Mo de journal binaire toutes les 5 secondes, nous avons observé les effets suivants :

• Chaque fois que la grande opération UPDATE est validée, le nombre de transactions par seconde (TPS) chute fortement.

• L'impact sur les performances est proportionnel à la taille du journal binaire : plus le journal binaire généré par la transaction est volumineux, plus l'impact sur la latence des autres charges de travail est important.

La figure suivante illustre l'impact des transactions volumineuses sur une charge de travail en cours d'exécution.

Les opérations liées à UPDATE :

CREATE TABLE t_large (a INT, b LONGTEXT) ENGINE = InnoDB;

# Insert a row with 256 MB of text. The resulting UPDATE generates 512 MB of binlog events.
INSERT INTO t_large VALUES (1, repeat('a', 256000000)); 

UPDATE t_large SET a = a + 1;

Effets de l'optimisation

• Stabilité du TPS considérablement améliorée

  • Avant l'optimisation : l'opération UPDATE volumineuse, qui s'exécute toutes les 5 secondes, provoque de fortes fluctuations du TPS.

  • Après l'optimisation (ligne orange) : l'impact de l'opération UPDATE volumineuse sur le TPS est presque éliminé.

  

• Aucune fluctuation significative de la latence

  • Comme le montre la ligne orange (après optimisation), l'impact des opérations UPDATE de différentes tailles sur la latence n'est plus significatif.

  • Même lorsque la taille du journal binaire dépasse 512 Mo, la latence de validation des autres transactions n'est pas significativement affectée.

  

Fonctionnement

Cache du journal binaire

Le cache du journal binaire est un espace temporaire au niveau de la session utilisé pour mettre en mémoire tampon les événements du journal binaire. Chaque session dispose de son propre cache de journal binaire, composé d'un cache mémoire (tampon) et d'un fichier temporaire. La taille du cache mémoire est contrôlée par le paramètre binlog_cache_size. Lorsqu'une transaction est suffisamment volumineuse pour remplir le cache mémoire, ses événements sont écrits dans le fichier temporaire.

Pendant l'exécution de la transaction, les événements générés sont temporairement stockés dans le cache du journal binaire. Au moment de la validation, le système doit lire ces événements séquentiellement depuis le cache du journal binaire, mettre à jour la position de fin (end_pos) et la somme de contrôle pour chaque événement, puis les écrire dans le fichier de journal binaire. Pour garantir que les événements de la transaction soient contigus dans le fichier de journal binaire, un verrou protège l'ensemble du processus. Tant qu'une transaction détient ce verrou pour écrire dans le fichier de journal binaire, toutes les autres transactions en cours de validation sont bloquées.

Problèmes liés à l'écriture du journal binaire pour les transactions volumineuses

L'écriture de ces événements dans le fichier de journal binaire lors de la validation peut être longue et avoir un impact sévère sur l'instance de deux manières principales :

• Le processus détient un verrou d'écriture du journal binaire, rendant l'instance entière inaccessible en écriture pendant toute la durée de l'écriture.

• Le processus d'écriture consomme des ressources d'E/S importantes. Dans les environnements disposant d'une capacité d'E/S limitée, cela peut provoquer le blocage complet de l'instance.

Optimisation binlog cache free flush

AliSQL repense les fichiers temporaires utilisés par le cache du journal binaire, permettant leur promotion directe en fichiers de journal binaire. Lorsque cette fonctionnalité est activée, la validation d'une transaction volumineuse promeut son fichier temporaire directement dans un nouveau fichier de journal binaire. Ce processus est extrêmement rapide, consomme un minimum de ressources d'E/S et élimine complètement les impacts négatifs de l'écriture des journaux binaires pour les transactions volumineuses.

Modifications apportées au cache du journal binaire

Pour permettre la promotion directe d'un fichier temporaire du cache du journal binaire en fichier de journal binaire, AliSQL modifie l'utilisation du cache du journal binaire de deux manières clés :

• Lors de l'écriture dans le fichier temporaire du cache du journal binaire, un espace est réservé au début du fichier. Pendant le processus de promotion, cet espace est utilisé pour stocker les événements d'en-tête du journal binaire.

• Lors de l'écriture dans le cache du journal binaire, la position de fin (end_pos) de chaque événement est calculée en fonction de la taille de cet espace réservé.

Promotion du fichier de journal binaire

Lorsqu'une transaction volumineuse est validée, son fichier temporaire du cache du journal binaire est promu directement dans un nouveau fichier de journal binaire. Au cours de ce processus, l'en-tête du fichier de journal binaire et les événements d'en-tête initiaux sont écrits dans l'espace réservé. Cet espace réservé contient quatre composants principaux :

• En-tête de fichier : un marqueur de 4 octets, [ 0xFE 'bin'], est écrit au début de chaque fichier de journal binaire pour l'identifier comme tel.

• Événements d'en-tête : incluent l'événement de description de format et l'événement GTID précédent.

• Événement vide : un type d'événement existant et ignorable est utilisé pour remplir tout l'espace réservé restant.

• Événement GTID : le GTID de la transaction volumineuse est généré pendant la phase de validation, et son événement est également écrit dans l'espace réservé.

Le contenu suivant l'espace réservé se compose des événements du cache du journal binaire d'origine, qui incluent généralement des événements Query, Table map, Row et Xid.

Un fichier de journal binaire promu par cette fonctionnalité diffère d'un fichier standard de deux manières :

• Il contient un événement vide supplémentaire.

• La somme de contrôle pour ce fichier est désactivée par défaut.

La fonctionnalité binlog cache free flush ne modifie pas le format du journal binaire. La réplication et les outils tiers qui s'appuient sur les fichiers de journal binaire ne sont pas affectés.