O PolarDB-X 1.0 distribui operações de linguagem de definição de dados (DDL) entre todos os shardings de tabela para execução paralela. Quando um comando DDL falha ou trava, use este guia para diagnosticar a causa e restaurar a consistência do schema.
Funcionamento do DDL no PolarDB-X 1.0
Cada comando DDL se propaga simultaneamente para todos os shardings de banco de dados. Esse modelo paralelo tem uma propriedade importante:
Uma falha em um sharding não afeta os demais. Cada sharding executa independentemente.
Como é possível tentar novamente operações DDL com falha e erros em shardings que já concluíram a operação não afetam os outros, basta garantir que todos os shardings de tabela compartilhem o mesmo schema ao final.
Use o comando CHECK TABLE para verificar se todos os shardings compartilham o mesmo schema após qualquer problema de DDL.
Tipos de falha de DDL
As falhas de DDL dividem-se em duas categorias:
Erros de execução — A instrução DDL falha em um ou mais shardings de banco de dados. Causas comuns incluem conflitos (a tabela ou coluna já existe) e espaço em disco insuficiente. Isso pode deixar os schemas dos shardings de tabela inconsistentes.
Operações de longa duração — A instrução DDL executa por um tempo anormalmente longo sem resposta. Isso ocorre quando um sharding demora muito para concluir a operação, cenário típico em operações Copy Table em tabelas grandes.
Determinar se uma operação DDL é rápida ou lenta
O MySQL executa DDL em dois modos:
In-Place — Modifica os metadados diretamente. É rápido e não copia dados.
Copy Table — Reconstrói a tabela inteira, incluindo todas as linhas de dados, logs e operações de buffer. É lento em tabelas grandes.
Verifique o valor de rows affected após a conclusão de uma operação DDL para identificar o modo utilizado:
|
Exemplo de operação |
Saída |
Modo |
|
Alterar valor padrão da coluna |
|
In-Place |
|
Adicionar um índice |
|
In-Place |
|
Alterar tipo de dados da coluna |
|
Copy Table |
Para obter uma referência completa sobre quais operações usam In-Place versus Copy Table, consulte Online DDL Operations na documentação do MySQL.
Teste antes de executar DDL em tabelas grandes:
Clone o schema da tabela para gerar uma tabela de teste.
Insira dados representativos.
Execute a operação DDL na tabela clonada.
Verifique o valor de
rows affected. Um valor diferente de zero indica que a operação reconstruirá toda a tabela. Agende-a para horários de baixa demanda.
Diagnosticar e recuperar de falhas de DDL
Siga este fluxo de decisão para lidar com falhas de DDL:
Run CHECK TABLE
|
Schema consistent? --> Yes --> Run SHOW CREATE TABLE
|
Schema as expected? --> Yes --> Done (DDL succeeded)
|
No
|
<-- <-- <-- <-- <--+
|
No
Run SHOW PROCESSLIST
|
DDL still running? --> Yes --> Wait for completion --> Return to CHECK TABLE
|
No
Retry DDL
|
Lock conflict error? --> Yes --> Run RELEASE DBLOCK --> Retry DDL
|
No
Return to SHOW PROCESSLISTEtapa 1: Verificar a consistência do schema
Execute CHECK TABLE para confirmar se todos os shardings de tabela compartilham o mesmo schema:
mysql> check table `xxxx`;Se o
CHECK TABLE
não retornar nenhuma saída no Data Management Service (DMS), execute-o pela linha de comando.
Um schema consistente retorna uma única linha com status OK:
+----------------------------+-------+----------+----------+
| TABLE | OP | MSG_TYPE | MSG_TEXT |
+----------------------------+-------+----------+----------+
| TDDL5_APP.xxxx | check | status | OK |
+----------------------------+-------+----------+----------+
1 row in set (0.05 sec)Caso o resultado contenha mais de uma linha ou o status não seja OK, os shardings apresentam schemas inconsistentes. Prossiga para a etapa 2.
Etapa 2: Verificar o conteúdo do schema
Execute SHOW CREATE TABLE para conferir o schema real:
mysql> show create table `xxxx`;Exemplo de saída:
+---------+------------------------------------------------------------------------------------------------------------------+
| Table | Create Table |
+---------+------------------------------------------------------------------------------------------------------------------+
| xxxx | CREATE TABLE `xxxx` (
`id` int(11) NOT NULL DEFAULT '0',
`NAME` varchar(1024) NOT NULL DEFAULT '',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 dbpartition by hash(`id`) tbpartition by hash(`id`) tbpartitions 3 |
+---------+------------------------------------------------------------------------------------------------------------------+
1 row in set (0.05 sec)Se o schema corresponder ao esperado após a operação DDL, o DDL foi concluído com sucesso. Caso contrário, prossiga para a etapa 3.
Etapa 3: Verificar operações DDL em execução
Algumas operações DDL são lentas e não produzem saída imediata. Execute SHOW PROCESSLIST para visualizar todas as instruções SQL ativas:
mysql> SHOW PROCESSLIST WHERE COMMAND != 'Sleep';Exemplo de saída:
+---------------+-----------+--------------------+-------------+---------+-----------------------------------------------------------------------+------------------------------------------------------------------------------------------------------+-----------+---------------+-----------+
| ID | USER | DB | COMMAND | TIME | STATE | INFO | ROWS_SENT | ROWS_EXAMINED | ROWS_READ |
+---------------+-----------+--------------------+-------------+---------+-----------------------------------------------------------------------+------------------------------------------------------------------------------------------------------+-----------+---------------+-----------+
| 0-0-352724126 | ifisibhk0 | test_123_wvvp_0000 | Query | 15 | Sending data | /*DRDS /42.120.74.88/ac47e5a72801000/ */select `t_item`.`detail_url`,SUM(`t_item`.`price`) from `t_i | NULL | NULL | NULL |
| 0-0-352864311 | cowxhthg0 | NULL | Binlog Dump | 13 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL | NULL | NULL | NULL |
| 0-0-402714566 | ifisibhk0 | test_123_wvvp_0005 | Query | 14 | Sending data | /*DRDS /42.120.74.88/ac47e5a72801000/ */select `t_item`.`detail_url`,`t_item`.`price` from `t_i | NULL | NULL | NULL |
| 0-0-402714795 | ifisibhk0 | test_123_wvvp_0005 | Alter | 114 | Sending data | /*DRDS /42.120.74.88/ac47e5a72801000/ */ALTER TABLE `Persons` ADD `Birthday` date | NULL | NULL | NULL |
......
+---------------+-----------+--------------------+-------------+---------+-----------------------------------------------------------------------+------------------------------------------------------------------------------------------------------+-----------+---------------+-----------+
12 rows in set (0.03 sec)Colunas essenciais para solução de problemas de DDL:
|
Coluna |
O que observar |
|
|
ID do comando — use para cancelar uma operação específica |
|
|
Segundos de execução do comando — valores altos indicam uma operação lenta |
|
|
Instrução SQL completa — identifica a qual DDL lógico pertence um comando de sharding |
Ao encontrar uma operação DDL em execução há muito tempo, cancele-a com:
KILL '0-0-402714795';Uma única instrução DDL lógica no PolarDB-X 1.0 corresponde a vários comandos de sharding de banco de dados. Para interromper uma operação DDL lógica, talvez seja necessário cancelar múltiplos comandos. Use a coluna INFO para identificar quais comandos pertencem à mesma instrução lógica.
Após o cancelamento, retorne à etapa 1 para verificar a consistência do schema.
Etapa 4: Tentar novamente a operação DDL
Se nenhum DDL estiver em execução e o schema ainda estiver inconsistente, tente executar novamente a operação DDL no PolarDB-X 1.0. Erros relatados em shardings onde a operação já foi concluída com sucesso não afetam a reexecução nos demais shardings.
Em caso de sucesso na nova tentativa, retorne à etapa 1 para verificar a consistência.
Se surgir um erro de Lock conflict, prossiga para a etapa 5.
Etapa 5: Liberar o bloqueio de DDL
Causa do conflito de bloqueio
O PolarDB-X 1.0 adquire um bloqueio de DDL antes de executar qualquer operação desse tipo e o libera ao concluir. Se você cancelar uma operação DDL com KILL antes da conclusão, o bloqueio pode não ser liberado automaticamente. Qualquer tentativa subsequente de DDL na mesma tabela falhará com:
Lock conflict , maybe last DDL is still runningLiberar o bloqueio
Execute o seguinte comando para liberar o bloqueio de DDL:
RELEASE DBLOCK;Após liberar o bloqueio, tente novamente a operação DDL (etapa 4). Para minimizar riscos, execute o DDL em horários de baixa demanda ou quando o serviço estiver parado.
Perguntas frequentes
Por que o DMS ou outro cliente não mostra o schema atualizado?
O PolarDB-X 1.0 mantém um banco de dados sombra no RDS, localizado no sharding de banco de dados 0. Esse banco de dados sombra tem o mesmo nome do banco de dados lógico do PolarDB-X 1.0 e armazena todos os metadados do banco de dados lógico, incluindo schemas. Clientes como o DMS leem o schema desse banco de dados sombra, e não diretamente dos shardings.
Se a operação DDL atualizou os schemas dos shardings, mas não o banco de dados sombra, os clientes exibirão o schema antigo. Para corrigir isso, conecte-se diretamente ao banco de dados sombra e execute a mesma operação DDL na tabela.
O comando
CHECK TABLE
não verifica se o schema do banco de dados sombra está consistente com o schema do banco de dados lógico do PolarDB-X 1.0. Se o DMS mostrar um schema inesperado após o
CHECK TABLE
retornar
OK
, é provável que o banco de dados sombra esteja dessincronizado.
Como lidar com códigos de erro de DDL como TDDL-4500 ERR_PARSER?
Consulte Códigos de erro para obter a lista completa de códigos de erro do PolarDB-X 1.0 e suas soluções.