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:
-
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
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
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 TABLEincorretamente.
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.
Tópicos
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
Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/
. -
No painel de navegação, escolha Performance Insights.
-
Escolha uma instância de banco de dados. O painel do Performance Insights dessa instância de banco de dados é exibido.
-
No gráfico Database load (Carga de banco de dados), escolha Slice by wait (Segmentar por espera).
-
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
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.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:
-
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.
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
