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.
Rubriques
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
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_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 en savoir plus sur les différents verrous InnoDB et les types de verrous susceptibles d'entraîner des conflits, consultez InnoDB Locking
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 TABLEde 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.
Rubriques
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
Connectez-vous à l'AWS Management Console et ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/
. -
Dans le volet de navigation, choisissez Performance Insights.
-
Choisissez une instance de base de données. Le tableau de bord Performance Insights correspondant à cette instance de base de données s'affiche.
-
Dans le graphique Database load (Charge de base de données), choisissez Slice by wait (Tranche par attente).
-
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 de la résolution des problèmes à l'aide de Performance Insights, consultez le billet de blog AWS Database 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.09.0 | +-----------+------------------+ 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.
Pour plus d'informations sur l'identification des transactions de blocage, consultez Using InnoDB Transaction and Locking Information
