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_context : COND _wait_status

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.

Versions de moteur prises en charge

Ces informations relatives aux événements d'attente sont prises en charge pour les versions de moteur suivantes :

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.

My SQL utilise le verrouillage des métadonnées pour gérer l'accès simultané aux objets de base de données et pour garantir 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 la section Verrouillage des métadonnées dans Ma SQL documentation.

La liste Mes SQL processus indique cette session dans son étatwaiting for metadata lock. Dans Performance Insights, si Performance_schema est activé, l'événement synch/cond/sql/MDL_context::COND_wait_statusapparaî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 plus de détails sur les différents verrous InnoDB et les types de verrous susceptibles de provoquer des conflits, consultez la section Verrouillage d'InnoDB dans la section Ma documentation. SQL

Causes probables de l'allongement des temps 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 :

Actions

Nous recommandons différentes actions en fonction des causes de votre événement d'attente et de la version du cluster Aurora My SQL DB.

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 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 My SQL 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 :

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 My SQL version 2

Dans Aurora My SQL version 2, vous pouvez identifier la session bloquée directement en interrogeant des performance_schema tables ou des vues de sys schéma. 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 :

Pour plus d'informations sur l'identification des transactions bloquantes, consultez la section Utilisation des informations de transaction et de verrouillage d'InnoDB dans la section Ma SQL documentation.