Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

synch/cond/sql/MDL_context::COND_wait_status

L’evento synch/cond/sql/MDL_context::COND_wait_status si verifica quando ci sono thread in attesa del blocco dei metadati di una tabella.

Versioni del motore supportate

Queste informazioni sull'evento di attesa sono supportate per le seguenti versioni del motore:

Context

L'evento synch/cond/sql/MDL_context::COND_wait_status indica che ci sono thread in attesa di un blocco dei metadati di tabella. In alcuni casi, una sessione contiene un blocco di metadati su una tabella e un'altra sessione tenta di ottenere lo stesso blocco sulla stessa tabella. In tal caso, la seconda sessione attende l’evento di attesa synch/cond/sql/MDL_context::COND_wait_status.

MySQL utilizza il blocco dei metadati per gestire l'accesso simultaneo agli oggetti del database e garantire la coerenza dei dati. Il blocco dei metadati si applica a tabelle, schemi, eventi pianificati, tablespace e blocchi utente acquisiti con la funzione get_lock e i programmi memorizzati. I programmi memorizzati includono procedure, funzioni e attivazioni. Per ulteriori informazioni, consulta Blocco dei metadati nella documentazione di MySQL.

L'elenco dei processi MySQL mostra questa sessione nello stato waiting for metadata lock. In Approfondimenti sulle prestazioni, se Performance_schema è acceso, l'evento synch/cond/sql/MDL_context::COND_wait_status viene visualizzato.

Il timeout predefinito per una query in attesa di un blocco dei metadati si basa sul valore del parametro lock_wait_timeout, che viene impostato in modo predefinito a 31.536.000 secondi (365 giorni).

Per ulteriori dettagli sui diversi blocchi InnoDB e sui tipi di blocchi che possono causare conflitti, consultare Blocco InnoDB nella documentazione di MySQL.

Probabili cause di aumento delle attese

Quando l’evento synch/cond/sql/MDL_context::COND_wait_status appare più che normale, possibilmente indicando un problema di prestazioni, le cause tipiche includono le seguenti:

Azioni

Consigliamo diverse azioni a seconda delle cause dell'evento di attesa e della versione del cluster del database di Aurora MySQL.

Identificare le sessioni e le query che causano gli eventi

È possibile utilizzare Approfondimenti sulle prestazioni per mostrare le query bloccate dall’evento di attesa synch/cond/sql/MDL_context::COND_wait_status. Tuttavia, per identificare la sessione di blocco, eseguire una query sulle tabelle dei metadati da performance_schema e information_schema sul cluster del database.

In genere, i database con carico da moderato a significativo hanno eventi di attesa. Gli eventi di attesa possono essere accettabili se le prestazioni sono ottimali. Se le prestazioni non sono ottimali, esaminare dove il database impiega più tempo. Considerare gli eventi di attesa che contribuiscono al carico più elevato per scoprire se è possibile ottimizzare il database e l'applicazione per ridurre tali eventi.

Per una panoramica utile della risoluzione dei problemi con Approfondimenti sulle prestazioni, consulta il post del blog di AWS Database Analizzare i carichi di lavoro di Amazon Aurora MySQL con Approfondimenti sulle prestazioni.

Verifica la presenza di eventi passati

È possibile ottenere informazioni dettagliate su questo evento di attesa per verificare la presenza di occorrenze passate. Per fare ciò, completare questa procedura:

Le informazioni disponibili per l’identificazione e la risoluzione dei problemi degli eventi passati sono limitate. L'esecuzione di queste verifiche non mostra quale oggetto è in attesa di informazioni. Tuttavia, è possibile identificare le tabelle con un carico pesante al momento dell'evento e la serie di righe gestite di frequente che causano conflitti al momento del problema. È quindi possibile utilizzare queste informazioni per riprodurre il problema in un ambiente di test e fornire informazioni dettagliate sulla sua causa.

Esegui query su Aurora MySQL versione 2

In Aurora MySQL versione 2, è possibile identificare direttamente la sessione bloccata eseguendo una query sulle tabelle performance_schema o visualizzazione dello schema sys. Un esempio può illustrare come interrogare le tabelle per identificare query e sessioni di blocco.

Nel seguente output dell'elenco dei processi, l'ID di connessione 89 è in attesa di un blocco dei metadati e sta eseguendo un comando TRUNCATE TABLE. In una query sulle tabelle performance_schema o visualizzazioni dello schema sys, l'output mostra che la sessione di blocco è 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)

Successivamente, una query sulle tabelle performance_schema o visualizzazioni dello schema sys mostra che la sessione di blocco è 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)

Rispondere alla sessione di blocco

Quando si identifica la sessione, le opzioni includono quanto segue:

Per ulteriori informazioni su come identificare le transazioni di blocco, consulta Utilizzo delle informazioni sulle transazioni InnoDB e sul blocco nella documentazione di MySQL.