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.
# Réglage d'Aurora MySQL avec les insights proactifs Amazon DevOps Guru
Les insights proactifs DevOps Guru détectent les conditions problématiques connues sur vos clusters de bases de données Aurora MySQL avant qu'ils se produisent. DevOps Guru peut effectuer les opérations suivantes :
+ Éviter de nombreux problèmes courants liés aux bases de données en recoupant la configuration de votre base de données par rapport aux paramètres courants recommandés.
+ Vous alerter face à des problèmes critiques dans votre flotte qui, s'ils ne sont pas vérifiés, peuvent entraîner des problèmes plus importants ultérieurement.
+ Vous alerter face à des problèmes nouvellement découverts.
Chaque insight proactif contient une analyse de la cause du problème et des recommandations d'actions correctives.
**Topics**
+ [La longueur de la liste d’historique InnoDB a considérablement augmenté](proactive-insights.history-list.md)
+ [La base de données crée des tables temporaires sur le disque](proactive-insights.temp-tables.md)
# 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*à un*db-instance*. Cette augmentation affecte les performances d’arrêt des requêtes et des bases de données.
**Topics**
+ [Versions de moteur prises en charge](#proactive-insights.history-list.context.supported)
+ [Contexte](#proactive-insights.history-list.context)
+ [Causes probables de ce problème](#proactive-insights.history-list.causes)
+ [Actions](#proactive-insights.history-list.actions)
+ [Métriques pertinentes](#proactive-insights.history-list.metrics)
## 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.
**Topics**
+ [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é](#proactive-insights.history-list.actions.no-shutdown)
+ [Identifier les transactions de longue durée et y mettre fin](#proactive-insights.history-list.actions.long-txn)
+ [Identifier les hôtes et les utilisateurs principaux à l’aide de l’analyse des performances](#proactive-insights.history-list.actions.top-PI)
### 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éplicas en 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
```
1. Terminez chaque transaction de longue durée avec la procédure stockée [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill).
### 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` : cette métrique de compteur peut être consultée dans Performance Insights, ainsi que dans la table `INFORMATION_SCHEMA.INNODB_METRICS`. Pour plus d’informations, consultez [Tableau des métriques InnoDB INFORMATION\$1SCHEMA](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-metrics-table.html) 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` présente la même valeur que `RollbackSegmentHistoryListLength`.
+ `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 en savoir plus, vérifiez les transactions actives sur votre cluster de bases de données Aurora MySQL. Cette métrique est prise en charge pour Aurora MySQL versions 2.11 et ultérieures, et 3.08 et ultérieures.
+ `PurgeFinishedPoint` : le numéro de transaction jusqu’auquel 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 est prise en charge pour Aurora MySQL versions 2.11 et ultérieures, et 3.08 et ultérieures.
+ `TransactionAgeMaximum` : l’âge de la transaction en cours d’exécution active la plus ancienne. Cette CloudWatch métrique n'est disponible que pour Aurora MySQL version 3.08 et supérieure.
+ `TruncateFinishedPoint` : le numéro de transaction jusqu’auquel 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, consultez[Métriques de niveau instance pour Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
# La base de données crée des tables temporaires sur le disque
Votre récente utilisation des tables temporaires sur disque a augmenté de manière significative, jusqu'à*percentage*. La base de données crée environ des tables *number* temporaires par seconde. Cela peut avoir un impact sur les performances et augmenter les opérations sur le disque*db-instance*.
**Topics**
+ [Versions de moteur prises en charge](#proactive-insights.temp-tables.context.supported)
+ [Contexte](#proactive-insights.temp-tables.context)
+ [Causes probables de ce problème](#proactive-insights.temp-tables.causes)
+ [Actions](#proactive-insights.temp-tables.actions)
+ [Métriques pertinentes](#proactive-insights.temp-tables.metrics)
## Versions de moteur prises en charge
Ces données d’insight sont prises en charge pour toutes les versions d’Aurora MySQL.
## Contexte
Il est parfois nécessaire que le serveur MySQL crée une table temporaire interne lors du traitement d'une requête. Aurora MySQL peut contenir une table temporaire interne en mémoire, où elle peut être traitée par le moteur de stockage MEMORY TempTable ou stockée sur disque par InnoDB. Pour plus d'informations, consultez [Utilisation des tables temporaires internes dans MySQL](https://dev.mysql.com/doc/refman/5.6/en/internal-temporary-tables.html) dans le *manuel de référence de MySQL*.
## Causes probables de ce problème
Une augmentation du nombre de tables temporaires sur disque indique l'utilisation de requêtes complexes. Si la mémoire configurée est insuffisante pour stocker des tables temporaires en mémoire, Aurora MySQL crée les tables sur disque. Cela peut avoir un impact sur les performances et augmenter les opérations sur le disque.
## Actions
Nous vous recommandons différentes actions en fonction des causes de votre insight.
+ Pour Aurora MySQL version 3, nous vous recommandons d'utiliser le moteur TempTable de stockage.
+ Optimisez vos requêtes pour renvoyer moins de données en sélectionnant uniquement les colonnes nécessaires.
Si vous activez le schéma de performance alors que tous les instruments `statement` sont activés et temporisés, vous pouvez effectuer une requête `SYS.statements_with_temp_tables` pour récupérer la liste des requêtes utilisant des tables temporaires. Pour plus d'informations, consultez [Prérequis pour l'utilisation du schéma sys](https://dev.mysql.com/doc/refman/8.0/en/sys-schema-prerequisites.html) dans la documentation sur MySQL.
+ Envisagez d'indexer les colonnes impliquées dans les opérations de tri et de regroupement.
+ Réécrivez vos requêtes pour éviter les colonnes `BLOB` et `TEXT`. Ces colonnes utilisent toujours un disque.
+ Réglez les paramètres de base de données suivants : `tmp_table_size` et `max_heap_table_size`.
La valeur par défaut de ces paramètres est 16 Mio. Lorsque vous utilisez le moteur de stockage MEMORY pour des tables temporaires en mémoire, leur taille maximale est définie par la plus petite des valeurs `tmp_table_size` et `max_heap_table_size`. Lorsque cette taille maximale est atteinte, MySQL convertit automatiquement la table temporaire interne en mémoire en une table temporaire interne sur disque InnoDB. Pour plus d'informations, consultez [Utiliser le moteur TempTable de stockage sur Amazon RDS for MySQL et Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/).
**Note**
Lorsque vous créez explicitement des tables MEMORY avec CREATE TABLE, seule la variable `max_heap_table_size` détermine la taille maximale qu'une table peut prendre. Il n'y a pas non plus de conversion vers un format sur disque.
## Métriques pertinentes
Les métriques suivantes d'analyse des performances sont liées à cet insight :
+ Created\$1tmp\$1disk\$1tables
+ Created\$1tmp\$1tables
Pour plus d'informations, consultez [Created\$1tmp\$1disk\$1tables](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html#statvar_Created_tmp_disk_tables) dans la documentation sur MySQL.