synch/cond/sql/MDL_context::COND_wait_status

O evento synch/cond/sql/MDL_context::COND_wait_status ocorre quando há threads aguardando em um bloqueio de metadados de tabela.

Versões compatíveis do mecanismo

Essas informações de eventos de espera têm suporte nas seguintes versões do mecanismo:

Contexto

O evento synch/cond/sql/MDL_context::COND_wait_status indica que há threads aguardando um bloqueio de metadados de tabela. Em alguns casos, uma sessão mantém um bloqueio de metadados em uma tabela, e outra sessão tenta obter o mesmo bloqueio na mesma tabela. Nesse caso, a segunda sessão aguarda no evento de espera synch/cond/sql/MDL_context::COND_wait_status.

O MySQL utiliza o bloqueio de metadados para gerenciar o acesso simultâneo a objetos de banco de dados e garantir a consistência dos dados. O bloqueio de metadados é aplicável a tabelas, esquemas, eventos agendados, espaços de tabelas e bloqueios de usuários adquiridos com a função get_lock e programas armazenados. Programas armazenados incluem procedimentos, funções e acionadores. Para ter mais informações, consulte o tópico sobre Bloqueio de metadados, na documentação do MySQL.

A lista de processos do MySQL mostra esta sessão no estado waiting for metadata lock. No Performance Insights, se Performance_schema estiver habilitado, o evento synch/cond/sql/MDL_context::COND_wait_status será exibido.

O tempo limite padrão para uma consulta aguardando um bloqueio de metadados baseia-se no valor do parâmetro lock_wait_timeout, cujo padrão é 31.536.000 segundos (365 dias).

Para obter mais detalhes sobre os diferentes bloqueios do InnoDB e os tipos de bloqueios que podem causar conflitos, consulte o tópico sobre Bloqueio do InnoDB, na documentação do MySQL.

Possíveis causas do maior número de esperas

Quando o evento synch/cond/sql/MDL_context::COND_wait_status aparece mais que o normal, possivelmente indicando um problema de performance, as causas típicas incluem:

Ações

Convém tomar medidas diferentes, dependendo das causas do evento de espera e da versão do cluster de banco de dados Aurora MySQL.

Identificar as sessões e as consultas que estão causando os eventos

É possível utilizar o Performance Insights para mostrar consultas bloqueadas pelo evento de espera synch/cond/sql/MDL_context::COND_wait_status. Porém, para identificar a sessão de bloqueio, consulte tabelas de metadados de performance_schema e information_schema no cluster de banco de dados.

Em geral, bancos de dados com carga de moderada a significativa apresentam eventos de espera. Os eventos de espera podem ser aceitáveis quando a performance é ideal. Se a performance não for ideal, examine onde o banco de dados está passando a maior parte do tempo. Observe os eventos de espera que contribuem para a carga mais alta e descubra se é possível otimizar o banco de dados e a aplicação para reduzir esses eventos.

Para obter uma visão geral útil da solução de problemas de uso do Performance Insights, consulte a AWSPublicação no blog de banco de dados sobre como Analisar workloads do Amazon Aurora MySQL com o Performance Insights.

Verifique se há eventos anteriores

É possível obter insights sobre esse evento de espera para conferir se há ocorrências passadas dele. Para isso, conclua as seguintes ações:

As informações disponíveis para solucionar problemas com eventos anteriores são limitadas. A realização dessas verificações não mostra qual objeto está aguardando informações. No entanto, é possível identificar tabelas com alta carga na ocasião do evento e o conjunto de linhas operadas com frequência que estão causando conflito na ocasião do problema. Em seguida, você pode utilizar essas informações para reproduzir o problema em um ambiente de teste e fornecer insights sobre a sua causa.

Executar consultas no Aurora MySQL versão 2

No Aurora MySQL versão 2, é possível identificar a sessão bloqueada diretamente, consultando tabelas performance_schema ou visualizações de esquema sys. Um exemplo é capaz de ilustrar como consultar tabelas para identificar consultas e sessões de bloqueio.

Na saída da lista de processos a seguir, o ID da conexão 89 está aguardando um bloqueio de metadados e está executando um comando TRUNCATE TABLE. Em uma consulta nas tabelas performance_schema ou visualizações de esquema sys, a saída mostra que a sessão de bloqueio é 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)

Em seguida, uma consulta nas tabelas performance_schema ou visualizações de esquema sys mostra que a sessão de bloqueio é 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)

Responder à sessão de bloqueio

Ao identificar a sessão, suas opções incluem:

Para ter mais informações sobre como identificar transações de bloqueio, consulte o tópico sobre como Utilizar informações de transações e bloqueios do InnoDB, na documentação do MySQL.