Todos os produtos
Search
Central de documentação

PolarDB:Otimização de MDL (metadata lock)

Última atualização: Jun 28, 2026

O metadata lock (MDL) é um bloqueio interno do banco de dados que garante a consistência dos metadados da tabela durante operações de Data Definition Language (DDL). Transações padrão de leitura e escrita precisam adquirir um MDL read lock na tabela de destino, enquanto operações DDL exigem um MDL write lock na mesma tabela. Ao executar instruções DDL, observe os seguintes problemas relacionados a metadata locks:

  • Bloqueio

    Uma transação de longa duração que mantém um MDL read lock pode bloquear uma operação DDL e causar falha após tempo excessivo de espera para adquirir um MDL write lock. Além disso, como o MySQL utiliza um mecanismo de fair lock para MDLs, uma instrução DDL bloqueada também impede o avanço de todas as novas transações na fila para obter um MDL read lock.

  • Risco de deadlock

    A execução simultânea de várias instruções DDL e transações pode gerar solicitações de MDLs em ordens diferentes e causar deadlocks.

  • Exclusividade

    O MDL write lock é exclusivo. Quando uma operação DDL adquire esse tipo de bloqueio, todas as transações recebidas ficam bloqueadas por não conseguirem obter um MDL read lock. Isso pode reduzir o tráfego a zero. Embora o MySQL suporte Online DDL, essas operações ainda precisam adquirir brevemente um MDL write lock em etapas críticas e não evitam completamente o bloqueio da tabela.

Se esses problemas ocorrerem durante a execução de DDL, eles podem gerar muitas conexões de negócios bloqueadas e, em casos graves, provocar uma interrupção temporária do tráfego. O PolarDB-X oferece otimizações específicas para resolver essas questões de metadata lock e eliminar tais riscos.

Otimização de MDL preemptivo

O PolarDB-X suporta a otimização de MDL preemptivo. Esse recurso elimina o risco de bloqueios causados por metadata locks durante a execução de DDL.

Versões suportadas

Este recurso está disponível no PolarDB-X versão 5.4.17-16952556 e posteriores.

Funcionamento

Ao executar uma instrução DDL que requer um MDL write lock, se o tempo de espera para adquirir o bloqueio for excessivo, o PolarDB-X encerra automaticamente a conexão da transação de longa duração que bloqueia a DDL.

A tabela a seguir ilustra um cenário em que uma instrução DDL e uma nova transação são bloqueadas por uma transação de longa duração sem essa otimização.

Tabela 1

Etapa

Sessão 1

Sessão 2

Sessão 3

1

begin;

-

begin;

2

insert into tb0 values(1);

-- Adquire um MDL read lock em tb0.

-

-

3

-- A transação não é confirmada para simular uma transação de longa duração.

-

-

4

-

alter table tb0 add column col int;

-- Tenta adquirir um MDL write lock em tb0 e é bloqueada pela transação de longa duração.

-

5

-

-

select id from tb0;

-- Tenta adquirir um MDL read lock em tb0 e é bloqueada.

A saída a seguir mostra o processo de execução com a otimização de MDL preemptivo ativada. As etapas são as mesmas da Tabela 1.

-- session1
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into tb0 values(1);
Query OK, 1 row affected (0.16 sec)
mysql> select version();
ERROR 2013 (HY000): Lost connection to MySQL server during query
No connection. Trying to reconnect...
Connection id:    46
-- session2
mysql> alter table tb0 add column col int;
Query OK, 0 rows affected (29.17 sec)
-- session3
mysql> select id from tb0;
Empty set (1.04 sec)

Conforme mostrado na saída, a otimização de MDL preemptivo encerra a conexão da transação de longa duração na Sessão 1. Isso permite que a instrução DDL na Sessão 2 seja executada com sucesso e garante que a nova transação na Sessão 3 funcione normalmente.

Detecção distribuída de deadlock de metadados

O PolarDB-X suporta detecção distribuída de deadlock de metadados. Esse recurso identifica e resolve deadlocks envolvendo metadata locks durante a execução de DDL, permitindo que as operações DDL e outras transações continuem.

Versões suportadas

Esse recurso está disponível no PolarDB-X versão 5.4.17-16952556 e posteriores.

Funcionamento

O PolarDB-X verifica periodicamente as relações de espera de bloqueio entre transações e instruções DDL. Caso detecte um deadlock, o PolarDB-X encerra automaticamente uma das transações conflitantes para garantir que a DDL e as demais transações prossigam.

A tabela a seguir apresenta um cenário típico de deadlock envolvendo metadata locks.

Tabela 2

Etapa

Sessão 1

Sessão 2

Sessão 3

Sessão 4

1

begin;

-- Inicia a transação 1.

begin;

-- Inicia a transação 2.

-

-

2

insert into t1 values(1);

-- Adquire um MDL read lock em t1.

insert into t2 values(1);

-- Adquire um MDL read lock em t2.

-

-

3

-

-

alter table t1 add column col int;

-- Inicia a DDL 1, que tenta adquirir um MDL write lock em t1 e é bloqueada.

alter table t2 add column col int;

-- Inicia a DDL 2, que tenta adquirir um MDL write lock em t2 e é bloqueada.

4

insert into t2 values(2);

-- Tenta adquirir um MDL read lock em t2, mas é bloqueada pela DDL 2 devido ao mecanismo de fair lock.

insert into t1 values(2);

-- Tenta adquirir um MDL read lock em t1, mas é bloqueada pela DDL 1 devido ao mecanismo de fair lock.

-

-

A saída a seguir demonstra como o PolarDB-X resolve o deadlock da Tabela 2 usando a detecção distribuída de deadlock de metadados. As etapas de execução são as mesmas da tabela.

-- Session 1
mysql> begin;
Query OK, 0 rows affected (0.01 sec)
mysql> insert into t1 values(1);
Query OK, 1 row affected (0.12 sec)
mysql> insert into t2 values(2);
Query OK, 1 row affected (0.02 sec)
mysql> commit;
Query OK, 0 rows affected (0.99 sec)

-- Session 2
mysql> begin;
Query OK, 0 rows affected (0.01 sec)
mysql> insert into t2 values(1);
Query OK, 1 row affected (0.08 sec)
mysql> insert into t1 values(2); -- An MDL deadlock is detected. The connection is killed and the transaction is rolled back.
ERROR 2013 (HY000): Lost connection to MySQL server during query
No connection. Trying to reconnect...
Connection id:    14
Current database: d0

-- Session 3
mysql> alter table t1 add column col int;
Query OK, 0 rows affected (2 min 38.30 sec)

-- Session 4
mysql> alter table t2 add column col int;
Query OK, 0 rows affected (2 min 59.85 sec)

Após a criação do cenário de deadlock da Tabela 2, o PolarDB-X detecta o problema e opta por encerrar a transação 2. Essa reversão permite que a transação 1, a DDL 1 e a DDL 2 sejam concluídas.

Otimização de MDL de versão dupla

Para DDLs executadas logicamente, o PolarDB-X suporta metadados de versão dupla e os respectivos metadata locks de versão dupla. Isso permite executar essas operações DDL sem jamais bloquear tabelas ou reduzir o tráfego a zero.

Limitações

Essa otimização aplica-se a todas as instruções DDL executadas logicamente no PolarDB-X. Para verificar se uma instrução DDL é executada logicamente, consulte Online DDL.

Funcionamento

O PolarDB-X implementa DDL lógica com base no princípio de Online Schema Change. Ele divide a versão de metadados de uma operação DDL lógica em várias versões menores, permitindo que os metadados evoluam com segurança dentro da instância do PolarDB-X. Por exemplo, uma instrução CREATE GLOBAL INDEX DDL no PolarDB-X envolve múltiplas transições de versão: ABSENT(Vn), DELETE_ONLY(Vn+1), WRITE_ONLY(Vn+2) e PUBLISH(Vn+3). Além disso, o PolarDB-X associa um metadata lock separado a cada uma dessas versões menores.

Graças ao mecanismo de Online Schema Change, duas versões de metadados podem coexistir, não apenas em diferentes nós de computação no cluster, mas também dentro de um único nó. Portanto, quando uma operação DDL lógica começa a evoluir a versão dos metadados, o PolarDB-X adquire o MDL write lock apenas para a versão antiga dos metadados durante cada transição. Isso permite que novas transações acessem a nova versão dos metadados e adquiram o MDL read lock correspondente.

Com a otimização de MDL de versão dupla, as operações DDL lógicas no PolarDB-X podem ser executadas sem nunca bloquear tabelas ou reduzir o tráfego a zero.