Use the quick diagnosis and deadlock analysis features - PolarDB: Central de Documentação do Alibaba Cloud

Quando ocorre um deadlock ou contenção de locks no seu cluster PolarDB for MySQL, a análise de deadlocks ajuda a identificar a causa raiz sem a necessidade de analisar manualmente os logs do InnoDB. Esse recurso se integra ao Database Autonomy Service (DAS) para analisar deadlocks, bloqueios de transações e metadata locks em tempo real ou a partir de logs de erros históricos.

Como funciona

A análise de deadlocks oferece três modos:

Modo	Source de dados	Resultado obtido
Recent deadlock analysis	Saída do comando `SHOW ENGINE INNODB STATUS`	Análise do evento de deadlock mais recente. Se houver múltiplos deadlocks, apenas o último será analisado.
Full deadlock analysis	Logs de erros verificados em intervalos regulares	Tendências de deadlocks em um período, além de detalhes de cada evento.
Other lock analysis	Dados das tabelas `information_schema` e `performance_schema`, consultados em tempo real	Diagrama de dependência de metadata locks e diagrama de bloqueio de transações para as sessões atuais.

A Metadata lock analysis (parte da análise de outros locks) deduz as relações de espera por locks e gera o diagrama correspondente com base nos dados da tabela information_schema.processlist.

A análise de bloqueio de transações (também parte da análise de outros locks) examina as relações de bloqueio entre transações e produz o respectivo diagrama utilizando informações da information_schema.processlist, da information_schema.innodb_trx e das seguintes tabelas específicas por versão:

MySQL 5.6 ou 5.7: information_schema.innodb_lock_waits
MySQL 8.0: performance_schema.data_lock_waits

A análise de bloqueio de transações não é compatível com clusters PolarDB for MySQL que executam o MySQL 5.6.

Pré-requisitos

Antes de começar, certifique-se de que:

Seu cluster seja do tipo PolarDB for MySQL.
(Obrigatório para full deadlock analysis e other lock analysis) A edição DAS Cost-efficient Edition ou DAS Enterprise Edition esteja ativada no cluster. Essas edições estão disponíveis apenas em algumas regiões. Para verificar as regiões compatíveis, consulte Bancos de dados e regiões suportados. Para ativar uma das edições, veja Ativar e gerenciar DAS Economy Edition e DAS Enterprise Edition.

Configurações de parâmetros

Configure os parâmetros abaixo antes de executar uma análise. Para obter instruções detalhadas, consulte Configurar parâmetros de cluster e nó.

Modo de análise	Configurações de parâmetros necessárias
Recent deadlock analysis	Defina `innodb_deadlock_detect` como `ON`.
Full deadlock analysis	Defina `innodb_deadlock_detect` como `ON`. Além disso, defina `innodb_print_all_deadlocks` como `ON` e `log_error_verbosity` como `3`.
Transaction blocking analysis (other lock analysis)	Defina `performance_schema` como `ON`. (Apenas MySQL 8.0)

Executar um diagnóstico de deadlock

Faça login no console do PolarDB. No painel de navegação à esquerda, clique em Clusters. No canto superior esquerdo, selecione a região do seu cluster e clique no ID do cluster para acessar a página Basic Information.
No painel de navegação à esquerda, escolha Diagnostics and Optimization > Quick Diagnostics.
Clique na aba Deadlock Analysis.
Na página Deadlock Analysis, selecione seu cluster na lista suspensa Current Node e clique em Diagnose.
Na lista de resultados, localize a entrada mais recente em que Deadlock Detected exiba Yes e clique em View Details na coluna Details.
Na caixa de diálogo Deadlock Analysis, revise os resultados da análise. Clique em View Deadlock Log para visualizar o log bruto do deadlock.

Perguntas frequentes

Por que instruções UPDATE causam deadlocks e como corrigir isso?

Esse cenário ocorre quando duas transações mantêm, cada uma, um lock exclusivo (X lock) em linhas diferentes e aguardam pelo lock mantido pela outra. Por exemplo:

A Transação 1 executa UPDATE accounts SET balance = balance - 100 WHERE user_id = 1;, adquirindo um X lock em user_id = 1.
A Transação 2 executa UPDATE accounts SET balance = balance + 100 WHERE user_id = 2;, adquirindo um X lock em user_id = 2.

Se a Transação 1 tentar bloquear user_id = 2 enquanto a Transação 2 tenta bloquear user_id = 1, nenhuma delas poderá prosseguir, resultando em um deadlock.

Para evitar essa situação:

Atualize as linhas em uma ordem consistente em todas as transações (por exemplo, sempre bloqueie primeiro a linha com o menor ID).
Agrupe várias atualizações em uma única instrução em lote para reduzir a janela de contenção de locks.