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. # synch/cond/sql/MDL\$1context : :Cond\$1Wait\$1Status L'événement `synch/cond/sql/MDL_context::COND_wait_status` se produit lorsque des threads sont en attente de verrouillage des métadonnées de table. **Topics** + [Versions de moteur prises en charge](#ams-waits.cond-wait-status.context.supported) + [Contexte](#ams-waits.cond-wait-status.context) + [Causes probables de l'augmentation du nombre d'événements d'attente](#ams-waits.cond-wait-status.causes) + [Actions](#ams-waits.cond-wait-status.actions) ## Versions de moteur prises en charge Ces informations relatives aux événements d’attente sont prises en charge pour les versions de moteur suivantes : + Aurora MySQL versions 2 et 3 ## Contexte L'événement `synch/cond/sql/MDL_context::COND_wait_status` indique que des threads sont en attente de verrouillage des métadonnées de table. Dans certains cas, une session maintient un verrou de métadonnées sur une table et une autre tente d'obtenir le même verrou sur la même table. Si tel est le cas, la seconde session attend l'événement d'attente `synch/cond/sql/MDL_context::COND_wait_status`. MySQL utilise le verrouillage des métadonnées pour gérer l'accès simultané aux objets de base de données et assurer la cohérence des données. Le verrouillage des métadonnées s'applique aux tables, schémas, événements planifiés, espaces disque logiques et verrous utilisateur acquis avec la fonction `get_lock` et les programmes stockés. Les programmes stockés incluent des procédures, fonctions et déclencheurs. Pour plus d'informations, consultez [Metadata Locking](https://dev.mysql.com/doc/refman/5.7/en/metadata-locking.html) dans la documentation MySQL. La liste du processus MySQL affiche cette session dans l'état `waiting for metadata lock`. Dans Performance Insights, si `Performance_schema` est activé, l'événement `synch/cond/sql/MDL_context::COND_wait_status`apparaît. Le délai d'expiration par défaut d'une requête en attente d'un verrouillage des métadonnées est basé sur la valeur du paramètre `lock_wait_timeout`, qui s'élève par défaut à 31 536 000 secondes (365 jours). Pour en savoir plus sur les différents verrous InnoDB et les types de verrous susceptibles d'entraîner des conflits, consultez [InnoDB Locking](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) dans la documentation MySQL. ## Causes probables de l'augmentation du nombre d'événements d'attente Lorsque l'événement `synch/cond/sql/MDL_context::COND_wait_status` se produit plus souvent qu'à l'accoutumée, indiquant un possible problème de performance, les causes sont généralement les suivantes : **Transactions de longue durée** Une ou plusieurs transactions modifient une grande quantité de données et maintiennent des verrous sur les tables pendant très longtemps. **Transactions inactives** Une ou plusieurs transactions restent ouvertes pendant longtemps, sans être validées ou annulées. **Instructions DDL sur de grandes tables** Une ou plusieurs instructions en langage de définition de données (DDL), telles que `ALTER TABLE`, ont été exécutées sur de grandes tables. **Verrous de table explicites** Certains verrous de table explicites ne sont pas libérés en temps opportun. Par exemple, une application peut exécuter des instructions `LOCK TABLE` de manière incorrecte. ## Actions Nous vous recommandons différentes actions en fonction des causes d'apparition de votre événement d'attente et de la version du cluster de bases de données Aurora MySQL. **Topics** + [Identifier les sessions et les requêtes à l'origine des événements](#ams-waits.cond-wait-status.actions.identify) + [Rechercher des événements passés](#ams-waits.cond-wait-status.actions.past-events) + [Exécuter des requêtes sur Aurora MySQL version 2](#ams-waits.cond-wait-status.actions.run-queries-aurora-mysql-57) + [Répondre à la session de blocage](#ams-waits.cond-wait-status.actions.blocker) ### Identifier les sessions et les requêtes à l'origine des événements Vous pouvez utiliser Performance Insights pour afficher les requêtes bloquées par l'événement d'attente `synch/cond/sql/MDL_context::COND_wait_status`. Toutefois, pour identifier la session de blocage, interrogez les tables de métadonnées depuis `performance_schema` et `information_schema` sur le cluster de bases de données. En règle générale, les bases de données à charge modérée à importante présentent des événements d'attente. Les événements d'attente peuvent être acceptables si les performances sont optimales. Si les performances ne sont pas optimales, voyez où la base de données passe le plus de temps. Examinez les événements d'attente qui contribuent à la charge la plus élevée et voyez si vous pouvez optimiser la base de données et l'application afin de réduire ces événements. **Pour rechercher les requêtes SQL responsables d’une charge élevée** 1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse. 1. Dans le panneau de navigation, choisissez **Performance Insights**. 1. Choisissez une instance de base de données. Le tableau de bord Performance Insights correspondant à cette instance de base de données s'affiche. 1. Dans le graphique **Database load (Charge de base de données)**, choisissez **Slice by wait (Tranche par attente)**. 1. Au bas de la page, choisissez **Top SQL (Principaux éléments SQL)**. Le graphique répertorie les requêtes SQL responsables de la charge. Les requêtes situées en haut de la liste sont les plus responsables. Pour résoudre un goulet d’étranglement, concentrez-vous sur ces instructions. Pour une présentation utile du dépannage à l'aide de Performance Insights, consultez le billet de blog AWS consacré à la base de données [Analyze Amazon Aurora MySQL Workloads with Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/). ### Rechercher des événements passés Pour obtenir des informations sur cet événement d'attente, vous pouvez rechercher ses précédentes occurrences. Pour ce faire, effectuez les actions suivantes : + Vérifiez le langage de manipulation de données (DML), le débit DDL et la latence pour savoir si la charge de travail a changé. Vous pouvez utiliser Performance Insights pour rechercher des requêtes en attente sur cet événement au moment du problème. Vous pouvez également afficher le résumé des requêtes exécutées à un moment proche du problème. + Si les journaux d'audit ou les journaux généraux sont activés pour le cluster de bases de données, vous pouvez rechercher toutes les requêtes exécutées sur les objets (schema.table) impliqués dans la transaction en attente. Vous pouvez également rechercher les requêtes dont l'exécution a pris fin avant la transaction. Les informations disponibles pour résoudre les problèmes liés aux événements passés sont limitées. L'exécution de ces vérifications n'indique pas quel objet est en attente d'informations. Cela étant, vous pouvez identifier les tables ayant présenté une charge importante au moment de l'événement et l'ensemble de lignes fréquemment utilisées ayant provoqué des conflits au moment du problème. Vous pouvez ensuite utiliser ces informations pour reproduire le problème dans un environnement de test et fournir des informations sur sa cause. ### Exécuter des requêtes sur Aurora MySQL version 2 Dans Aurora MySQL version 2, vous pouvez identifier directement la session bloquée en interrogeant les tables `performance_schema` ou les vues de schéma `sys`. Un exemple permet d'illustrer comment interroger des tables afin d'identifier les requêtes et les sessions de blocage. Dans la sortie de la liste de processus suivante, l'ID de connexion `89` attend sur un verrou de métadonnées et exécute une commande `TRUNCATE TABLE`. Dans une requête portant sur les tables `performance_schema` ou les vues de schéma `sys`, la sortie indique que la session de blocage est `76`. ``` MySQL [(none)]> select @@version, @@aurora_version; +-----------+------------------+ | @@version | @@aurora_version | +-----------+------------------+ | 5.7.12 | 2.11.5 | +-----------+------------------+ 1 row in set (0.01 sec) MySQL [(none)]> show processlist; +----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+ | 2 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL | | 4 | rdsadmin | localhost | NULL | Sleep | 2 | NULL | NULL | | 5 | rdsadmin | localhost | NULL | Sleep | 1 | NULL | NULL | | 20 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL | | 21 | rdsadmin | localhost | NULL | Sleep | 261 | NULL | NULL | | 66 | auroramysql5712 | 172.31.21.51:52154 | sbtest123 | Sleep | 0 | NULL | NULL | | 67 | auroramysql5712 | 172.31.21.51:52158 | sbtest123 | Sleep | 0 | NULL | NULL | | 68 | auroramysql5712 | 172.31.21.51:52150 | sbtest123 | Sleep | 0 | NULL | NULL | | 69 | auroramysql5712 | 172.31.21.51:52162 | sbtest123 | Sleep | 0 | NULL | NULL | | 70 | auroramysql5712 | 172.31.21.51:52160 | sbtest123 | Sleep | 0 | NULL | NULL | | 71 | auroramysql5712 | 172.31.21.51:52152 | sbtest123 | Sleep | 0 | NULL | NULL | | 72 | auroramysql5712 | 172.31.21.51:52156 | sbtest123 | Sleep | 0 | NULL | NULL | | 73 | auroramysql5712 | 172.31.21.51:52164 | sbtest123 | Sleep | 0 | NULL | NULL | | 74 | auroramysql5712 | 172.31.21.51:52166 | sbtest123 | Sleep | 0 | NULL | NULL | | 75 | auroramysql5712 | 172.31.21.51:52168 | sbtest123 | Sleep | 0 | NULL | NULL | | 76 | auroramysql5712 | 172.31.21.51:52170 | NULL | Query | 0 | starting | show processlist | | 88 | auroramysql5712 | 172.31.21.51:52194 | NULL | Query | 22 | User sleep | select sleep(10000) | | 89 | auroramysql5712 | 172.31.21.51:52196 | NULL | Query | 5 | Waiting for table metadata lock | truncate table sbtest.sbtest1 | +----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+ 18 rows in set (0.00 sec) ``` Ensuite, une requête portant sur les tables `performance_schema` ou les vues de schéma `sys` indique que la session de blocage est `76`. ``` MySQL [(none)]> select * from sys.schema_table_lock_waits; +---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+ | object_schema | object_name | waiting_thread_id | waiting_pid | waiting_account | waiting_lock_type | waiting_lock_duration | waiting_query | waiting_query_secs | waiting_query_rows_affected | waiting_query_rows_examined | blocking_thread_id | blocking_pid | blocking_account | blocking_lock_type | blocking_lock_duration | sql_kill_blocking_query | sql_kill_blocking_connection | +---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+ | sbtest | sbtest1 | 121 | 89 | auroramysql5712@192.0.2.0 | EXCLUSIVE | TRANSACTION | truncate table sbtest.sbtest1 | 10 | 0 | 0 | 108 | 76 | auroramysql5712@192.0.2.0 | SHARED_READ | TRANSACTION | KILL QUERY 76 | KILL 76 | +---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+ 1 row in set (0.00 sec) ``` ### Répondre à la session de blocage Après avoir identifié la session, vous pouvez procédez comme suit : + Contactez le propriétaire de l’application ou l’utilisateur. + Si la session de blocage est inactive, pensez à y mettre fin. Une telle action peut déclencher une longue restauration. Pour savoir comment mettre fin à une session, consultez [Mettre fin à une session ou à une requête](mysql-stored-proc-ending.md). Pour plus d'informations sur l'identification des transactions de blocage, consultez [Using InnoDB Transaction and Locking Information](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html) dans la documentation MySQL.