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:
-
Aurora MySQL versioni 2 e 3
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
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
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:
- Transazioni di lunga durata
-
Una o più transazioni stanno modificando una grande quantità di dati e mantengono i blocchi sulle tabelle per un tempo molto lungo.
- Transazioni inattive
-
Una o più transazioni rimangono aperte per un lungo periodo, senza che venga eseguito il commit o riprimisto a una precedente versione.
- Istruzioni DDL su tabelle grandi
-
Una o più istruzioni di definizione dei dati (DDL), ad esempio i comandi
ALTER TABLE, sono state eseguite su tabelle molto grandi. - Blocchi espliciti della tabella
-
Ci sono blocchi espliciti sulle tabelle che non vengono rilasciate in modo tempestivo. Ad esempio, potrebbe essere eseguita un'applicazione su istruzioni
LOCK TABLEimpropriamente.
Azioni
Consigliamo diverse azioni a seconda delle cause dell'evento di attesa e della versione del cluster del database di Aurora MySQL.
Argomenti
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 trovare query di SQL responsabili del carico elevato
Accedi alla AWS Management Console e apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/
. -
Nel pannello di navigazione scegli Approfondimenti sulle prestazioni.
-
Scegli un'istanza database. Viene visualizzato il pannello di controllo di Approfondimenti sulle prestazioni per l'istanza database.
-
Nel grafico Carico del database, scegli Dividi per attesa.
-
Nella parte inferiore della pagina scegli Prime Instruzioni SQL.
Il grafico elenca le query di SQL responsabili del carico. Quelli in cima all'elenco sono le più responsabili. Per risolvere un collo di bottiglia, occorre concentrarsi su queste istruzioni.
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:
-
Controllare il linguaggio di manipolazione dei dati (DML) e la velocità effettiva e la latenza del DDL per verificare se sono state apportate modifiche al carico di lavoro.
È possibile utilizzare Approfondimenti sulle prestazioni per trovare query in attesa di questo evento al momento del problema. Inoltre, è possibile visualizzare il digest delle query eseguite vicino al momento del problema.
-
Se i registri di verifica o i registri generali sono attivati per il cluster el database, è possibile verificare la presenza di tutte le query eseguite sugli oggetti (schema.table) coinvolti nella transazione in attesa. È inoltre possibile verificare la presenza delle query completate in esecuzione prima della transazione.
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:
-
Contattare il proprietario dell'applicazione o l'utente.
-
Se la sessione di blocco è inattiva, considerare di terminare la sessione di blocco. Questa azione potrebbe innescare un lungo ripristino dello stato precedente. Per informazioni su come terminare una sessione, consulta Terminare una sessione o una query.
Per ulteriori informazioni su come identificare le transazioni di blocco, consulta Utilizzo delle informazioni sulle transazioni InnoDB e sul blocco
