# synch/cond/sql/MDL\$1context::COND\$1wait\$1status O evento `synch/cond/sql/MDL_context::COND_wait_status` ocorre quando há threads aguardando em um bloqueio de metadados de tabela. **Topics** + [Versões compatíveis do mecanismo](#ams-waits.cond-wait-status.context.supported) + [Contexto](#ams-waits.cond-wait-status.context) + [Possíveis causas do maior número de esperas](#ams-waits.cond-wait-status.causes) + [Ações](#ams-waits.cond-wait-status.actions) ## Versões compatíveis do mecanismo Essas informações de eventos de espera têm suporte nas seguintes versões do mecanismo: + Aurora MySQL versões 2 e 3 ## 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](https://dev.mysql.com/doc/refman/5.7/en/metadata-locking.html), 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](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html), 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: **Transações de longa execução** Uma ou mais transações estão modificando muitos dados e mantendo bloqueios nas tabelas por muito tempo. **Transações ociosas** Uma ou mais transações permanecem abertas por muito tempo, sem serem confirmadas ou revertidas. **Instruções DDL em tabelas grandes** Uma ou mais instruções de definição de dados (DDL), como comandos `ALTER TABLE`, foram executadas em tabelas muito grandes. **Bloqueios de tabela explícitos** Existem bloqueios explícitos em tabelas que não estão sendo liberados em tempo hábil. Por exemplo, uma aplicação pode executar instruções `LOCK TABLE` incorretamente. ## 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. **Topics** + [Identificar as sessões e as consultas que estão causando os eventos](#ams-waits.cond-wait-status.actions.identify) + [Verifique se há eventos anteriores](#ams-waits.cond-wait-status.actions.past-events) + [Executar consultas no Aurora MySQL versão 2](#ams-waits.cond-wait-status.actions.run-queries-aurora-mysql-57) + [Responder à sessão de bloqueio](#ams-waits.cond-wait-status.actions.blocker) ### 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 localizar consultas SQL que são responsáveis pela carga alta** 1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. No painel de navegação, escolha **Performance Insights**. 1. Escolha uma instância de banco de dados. O painel do Performance Insights dessa instância de banco de dados é exibido. 1. No gráfico **Database load** (Carga de banco de dados), escolha **Slice by wait** (Segmentar por espera). 1. Na parte inferior da página, escolha **Top SQL** (SQL principal). O gráfico mostra as consultas SQL que são responsáveis pela carga. Os que estão no topo da lista são os mais responsáveis. Para solucionar um gargalo, concentre-se nessas instruções. 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](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-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: + Verifique a linguagem de manipulação de dados (DML) e a taxa de transferência e latência de DDL para ver se houve alterações na workload. É possível utilizar o Performance Insights para encontrar consultas aguardando esse evento na ocasião do problema. Também é possível visualizar o resumo das consultas executadas próximo à ocorrência do problema. + Se logs de auditoria ou logs gerais estiverem habilitados para o cluster de banco de dados, será possível verificar todas as consultas executadas nos objetos (schema.table) envolvidos na transação em espera. Você também pode verificar consultas com execução concluída antes da transação. 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.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) ``` 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: + Entre em contato com o proprietário da aplicação ou o usuário. + Se a sessão de bloqueio estiver ociosa, considere encerrá-la. Essa ação pode desencadear uma reversão longa. Para saber como encerrar uma sessão, consulte [Encerrar uma sessão ou consulta](mysql-stored-proc-ending.md). 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](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html), na documentação do MySQL.