La longueur de la liste d'historique InnoDB a considérablement augmenté - Amazon Aurora
Versions de moteur prises en chargeContexteCauses probables de ce problèmeActionsMétriques pertinentes

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

La longueur de la liste d'historique InnoDB a considérablement augmenté

À partir de date maintenant, votre liste d'historique des modifications de ligne a augmenté de manière significative, jusqu'lengthà undb-instance. Cette augmentation affecte les performances d'arrêt des requêtes et des bases de données.

Versions de moteur prises en charge

Ces données d'insight sont prises en charge pour toutes les versions d'Aurora MySQL.

Contexte

Le système de transaction InnoDB gère le contrôle de simultanéité multiversion (MVCC). Lorsqu'une ligne est modifiée, la version antérieure à la modification des données en cours de modification est stockée sous la forme d'un enregistrement d'annulation dans un journal d'annulation. Chaque enregistrement d'annulation comporte une référence à son enregistrement de rétablissement précédent, formant ainsi une liste liée.

La liste d'historique InnoDB est une liste globale des journaux d'annulation des transactions validées. MySQL utilise cette liste d'historique pour purger les enregistrements et les pages de journal lorsque les transactions n'ont plus besoin de l'historique. La longueur de la liste d'historique est le nombre total de journaux d'annulation contenant des modifications dans la liste d'historique. Chaque journal contient une ou plusieurs modifications. Si la liste d'historique InnoDB devient trop grande, indiquant un grand nombre d'anciennes versions de lignes, les arrêts des bases de données et des requêtes deviennent plus lents.

Causes probables de ce problème

Les causes typiques d'une longue liste d'historique sont les suivantes :

  • Transactions de longue durée, de lecture ou d'écriture

  • Lourde charge d'écriture

Actions

Nous vous recommandons différentes actions en fonction des causes de votre insight.

Ne commencer aucune opération impliquant un arrêt de base de données tant que la liste d'historique InnoDB n'a pas diminué

Étant donné qu'une longue liste d'historique InnoDB ralentit les arrêts de base de données, réduisez la taille de la liste avant de lancer des opérations impliquant un arrêt de base de données. Ces opérations incluent les mises à niveau des versions majeures de base de données.

Identifier les transactions de longue durée et y mettre fin

Vous pouvez trouver les transactions de longue durée en exécutant la requête information_schema.innodb_trx.

Note

Assurez-vous également de rechercher les transactions de longue durée sur les répliques de lecture.

Pour identifier les transactions de longue durée et y mettre fin

  1. Dans votre client SQL, exécutez la requête suivante :

    SELECT a.trx_id, 
      a.trx_state, 
      a.trx_started, 
      TIMESTAMPDIFF(SECOND,a.trx_started, now()) as "Seconds Transaction Has Been Open", 
      a.trx_rows_modified, 
      b.USER, 
      b.host, 
      b.db, 
      b.command, 
      b.time, 
      b.state 
FROM  information_schema.innodb_trx a, 
      information_schema.processlist b 
WHERE a.trx_mysql_thread_id=b.id
  AND TIMESTAMPDIFF(SECOND,a.trx_started, now()) > 10 
ORDER BY trx_started

  2. Terminez chaque transaction de longue durée avec la procédure mysql.rds_kill stockée.

Identifier les hôtes et les utilisateurs principaux à l'aide de l'analyse des performances

Optimisez les transactions afin qu'un grand nombre de lignes modifiées soient immédiatement validées.

Métriques pertinentes

Les métriques suivantes sont liées à cet insight :

  • trx_rseg_history_len— Ce contre-indicateur peut être consulté dans Performance Insights, ainsi que dans le INFORMATION_SCHEMA.INNODB_METRICS tableau. Pour plus d'informations, consultez le tableau des métriques InnoDB INFORMATION_SCHEMA dans la documentation MySQL.

  • RollbackSegmentHistoryListLength— Cette CloudWatch métrique Amazon mesure les journaux d'annulation qui enregistrent les transactions validées avec des enregistrements marqués de suppression. Ces enregistrements sont planifiés pour être traités par l'opération de purge InnoDB. La métrique trx_rseg_history_len a la même valeur queRollbackSegmentHistoryListLength.

  • PurgeBoundary— Le numéro de transaction jusqu'auquel la purge d'InnoDB est autorisée. Si cette CloudWatch métrique n'avance pas pendant de longues périodes, cela indique que la purge d'InnoDB est bloquée par des transactions de longue durée. Pour étudier, vérifiez les transactions actives sur votre cluster de base de données Aurora MySQL. Cette métrique n'est disponible que pour Aurora MySQL version 2.11 et versions supérieures, et pour les versions 3.08 et supérieures.

  • PurgeFinishedPoint— Le numéro de transaction jusqu'à lequel la purge d'InnoDB est effectuée. Cette CloudWatch métrique peut vous aider à examiner la rapidité de la purge d'InnoDB. Cette métrique n'est disponible que pour Aurora MySQL version 2.11 et versions supérieures, et pour les versions 3.08 et supérieures.

  • TransactionAgeMaximum— L'âge de la plus ancienne transaction active en cours. Cette CloudWatch métrique n'est disponible que pour Aurora MySQL version 3.08 et supérieure.

  • TruncateFinishedPoint— Numéro de transaction jusqu'à lequel la troncature d'annulation est effectuée. Cette CloudWatch métrique n'est disponible que pour Aurora MySQL version 2.11 et versions supérieures, et pour les versions 3.08 et supérieures.

Pour plus d'informations sur les CloudWatch métriques, consultezMétriques de niveau instance pour Amazon Aurora.