Como usar o Quick Diagnostics e a análise de deadlocks - PolarDB: Central de Documentação do Alibaba Cloud

O recurso Quick Diagnostics do PolarDB for MySQL integra funcionalidades do DAS. A análise de deadlocks permite analisar visualmente o deadlock mais recente do banco de dados.

Visão geral

A análise de deadlocks oferece suporte à avaliação multidimensional de deadlocks, bloqueios de transações e esperas por locks de metadados.

Importante

Os recursos de análise completa de deadlocks e outras análises de locks exigem os seguintes pré-requisitos:

A instância de banco de dados deve ser do PolarDB for MySQL.
Ative o DAS Economy Edition ou o DAS Enterprise Edition. Para obter a lista de regiões compatíveis, consulte Supported databases and regions for each edition. Para saber como ativar uma edição, consulte Gerencie logs de auditoria e serviços de O&M do DAS (antigo Economy Edition).

Análise de deadlocks recentes: o DAS examina o log de deadlock mais recente retornado pelo comando SHOW ENGINE INNODB STATUS. Se ocorrerem múltiplos deadlocks, apenas o último será analisado.
Análise completa de deadlocks: o DAS processa periodicamente os logs de erros para extrair informações sobre deadlocks. Também é possível visualizar tendências de deadlocks em um intervalo de tempo específico e consultar detalhes de cada ocorrência.
Outras análises de locks: com base nos dados de information_schema e performance_schema, o DAS avalia em tempo real os locks de metadados e os bloqueios de transações na sessão atual do banco de dados.
- Análise de locks de metadados: o DAS deduz as relações de espera por locks e gera um gráfico de relacionamentos com base em fontes como information_schema.processlist.
- Análise de bloqueio de transações: o DAS identifica relações de bloqueio entre transações e cria um gráfico correspondente com base em information_schema.processlist, information_schema.innodb_trx e nas tabelas específicas de versão: information_schema.innodb_lock_waits (para MySQL 5.6 e 5.7) e performance_schema.data_lock_waits (para MySQL 8.0).
  
  Nota
  Instâncias do PolarDB for MySQL 5.6 não oferecem suporte à análise de bloqueio de transações.

Requisitos de parâmetros

Para utilizar esses recursos de análise, defina os parâmetros obrigatórios.

Recurso	Parâmetro
Análise de deadlocks recentes	Ative o parâmetro `innodb_deadlock_detect`.
Análise completa de deadlocks	Ative o parâmetro `innodb_deadlock_detect`. Ative o parâmetro `innodb_print_all_deadlocks` e defina `log_error_verbosity=3`.
Análise de bloqueio de transações (em outras análises de locks)	Para instâncias PolarDB for MySQL 8.0, ative o parâmetro `performance_schema`.

Para modificar parâmetros da instância de banco de dados:

No PolarDB for MySQL, consulte Defina parâmetros de cluster e nó.

Procedimento

Faça login no console do PolarDB. No painel de navegação à esquerda, clique em Clusters, selecione a região do cluster e clique em ID do cluster desejado para abrir a página de detalhes.
No painel de navegação à esquerda, escolha Diagnostics and Optimization > Quick Diagnostics.
Clique em aba Deadlock Analytics.
Na página Deadlock Analytics, selecione o ID da instância desejada na lista Current Node e clique em Diagnose.
Na lista de resultados do diagnóstico, clique em View Details na coluna Details.

Nota
A opção View Details só está disponível quando Deadlock Detected for Yes.
Na caixa de diálogo Deadlock Analytics, revise os resultados detalhados do diagnóstico. Clique também em View Deadlock Log para visualizar o log do deadlock mais recente.

Perguntas frequentes

P: Por que uma instrução UPDATE causa deadlock e como resolver?

R: Um deadlock pode ocorrer quando duas transações mantêm, cada uma, um lock exclusivo (lock X) sobre um registro e tentam adquirir o lock da outra, formando uma espera circular. Exemplo:

Transação 1: UPDATE accounts SET balance = balance - 100 WHERE user_id = 1; tenta obter um lock exclusivo na conta do Usuário A (id=1).
Transação 2: UPDATE accounts SET balance = balance + 100 WHERE user_id = 2; tenta obter um lock exclusivo na conta do Usuário B (id=2).

Nota

Em seguida, a Transação 1 tenta bloquear o registro mantido pela Transação 2 (onde user_id=2) e precisa aguardar. Simultaneamente, a Transação 2 tenta bloquear o registro mantido pela Transação 1 (onde user_id=1) e também fica em espera. Esse bloqueio mútuo gera uma espera circular, resultando em um deadlock.

Solução: atualize os registros seguindo uma ordem consistente em todas as transações (por exemplo, atualizando sempre primeiro o registro com o menor ID). Outra alternativa é agrupar várias operações de atualização em um único lote para reduzir a contenção de locks.