Data Transmission Service:Migrar dados de um banco de dados TiDB autogerenciado para um cluster PolarDB for MySQL

Limites do banco de dados de origem

• Largura de banda de saída: O servidor do banco de dados de origem deve ter largura de banda de saída suficiente. Largura de banda insuficiente reduz a velocidade da migração.

• Chave primária ou restrição UNIQUE: As tabelas devem ter uma chave primária (PRIMARY KEY) ou restrição UNIQUE com todos os campos únicos. Sem essas restrições, o banco de dados de destino poderá conter registros duplicados.

• Limite de tabelas por tarefa: Ao migrar tabelas individuais com edições no nível de coluna (como renomear colunas), uma única tarefa suporta até 1.000 tabelas. Para mais de 1.000 tabelas, divida o trabalho em várias tarefas ou migre o banco de dados inteiro.

• Restrições de DDL durante a migração: Durante a migração de esquema e a migração completa de dados, não execute operações DDL que alterem o esquema do banco de dados ou das tabelas. A tarefa de migração falhará se operações DDL forem detectadas.

• Índices de prefixo: Os metadados do TiDB não armazenam comprimentos de índices de prefixo. Após a migração, os comprimentos dos índices de prefixo são perdidos, o que pode impedir a execução da instância. Corrija manualmente os comprimentos dos índices de prefixo para quaisquer tabelas afetadas após a migração.

• Requisitos de dados incrementais: A migração incremental de dados requer um cluster Kafka e componentes TiDB Binlog ou TiCDC. Consulte (Opcional) Configurar a coleta de dados incrementais.

Outros limites

• Incremental data partition: O DTS lê dados incrementais apenas da partição com ID 0 no tópico do Kafka.

• Inicialização de posição: Após criar uma tarefa com migração incremental, realize alterações ou insira dados de teste no banco de dados de origem prontamente para atualizar as informações de posição. A falta dessa ação pode causar falha na tarefa devido à latência excessiva.

• Caracteres de 4 bytes: Se os dados incluírem caracteres raros ou emojis (caracteres de 4 bytes), o banco de dados e as tabelas de destino devem usar o conjunto de caracteres UTF8mb4. Caso utilize a migração de esquema do DTS, defina também o parâmetro da instância character_set_server como UTF8mb4 no banco de dados de destino.

• Uso de recursos na migração completa: A migração completa de dados consome recursos de leitura e escrita tanto no banco de dados de origem quanto no de destino, aumentando a carga sobre eles. Avalie o desempenho do banco de dados antes de migrar e execute a migração completa em horários de baixa demanda (por exemplo, quando a carga da CPU estiver abaixo de 30%).

• Tamanho do tablespace após migração completa: Operações INSERT simultâneas durante a migração completa de dados causam fragmentação de tabela. O tablespace no banco de dados de destino será maior do que no banco de dados de origem após a conclusão da migração.

• Escritas no destino durante a migração: Escrever no banco de dados de destino durante a migração pode causar inconsistência de dados entre a origem e o destino.

• Precisão de FLOAT e DOUBLE: O DTS usa ROUND(COLUMN,PRECISION) para ler valores FLOAT e DOUBLE. A precisão padrão é de 38 dígitos para FLOAT e 308 dígitos para DOUBLE. Verifique se essas configurações de precisão atendem aos seus requisitos.

• Retomada automática: O DTS tenta retomar automaticamente tarefas que falharam nos últimos sete dias. Antes de alternar cargas de trabalho para a instância de destino, pare ou libere a tarefa do DTS, ou execute REVOKE para remover as permissões de escrita da conta do DTS na instância de destino.

• Falhas de DDL: Se uma instrução DDL falhar no banco de dados de destino, a tarefa do DTS continuará em execução. Visualize as instruções DDL com falha nos logs da tarefa. Consulte Visualizar logs da tarefa.

• Intervenção do suporte técnico: Se uma tarefa do DTS falhar, o suporte técnico tentará restaurá-la dentro de 8 horas. Durante a restauração, a tarefa pode ser reiniciada e parâmetros da tarefa (não parâmetros do banco de dados) podem ser modificados. Para os parâmetros que podem ser modificados, consulte a seção Modificar parâmetros da instância.

Etapa 1: Configurar um cluster Kafka

Use uma das seguintes opções:

• Cluster Kafka autogerenciado: Implante o Apache Kafka seguindo a documentação do Apache Kafka.

  Aviso

  Para lidar com o volume de dados de log binário do TiDB, aumente os seguintes parâmetros na configuração do seu Kafka. Consulte Configuração do Kafka.

  Componente	Parâmetro	Motivo
  Broker	message.max.bytes	Define o tamanho máximo de mensagem que o broker aceita. Eventos de log binário do TiDB podem ser grandes, portanto o limite padrão causa falhas de escrita.
  Broker	replica.fetch.max.bytes	Define o máximo de bytes que um follower pode buscar por solicitação. Deve ser pelo menos igual a message.max.bytes para replicar mensagens superdimensionadas.
  Consumer	fetch.message.max.bytes	Define o máximo de bytes que um consumer busca por partição. Deve ser pelo menos igual a message.max.bytes para que o DTS possa ler eventos completos.

• Message Queue for Apache Kafka: Utilize o serviço gerenciado de Kafka da Alibaba Cloud. Consulte Primeiros passos.

  Implante a instância do Message Queue for Apache Kafka na mesma virtual private cloud (VPC) do servidor do banco de dados de origem para reduzir a latência de rede e garantir conectividade estável.

Etapa 2: Criar um tópico Kafka

Crie um tópico no cluster Kafka ou na instância do Message Queue for Apache Kafka.

Etapa 3: Configurar TiDB Binlog ou TiCDC

Escolha um método com base no seu ambiente:

<details> <summary>Opção A: TiDB Binlog</summary>

Para minimizar o impacto da latência de rede, implante o componente Pump, o componente Drainer e o cluster Kafka em servidores que compartilhem a mesma rede interna do servidor do banco de dados TiDB de origem.

1. Implante os componentes Pump e Drainer. Consulte Implantação de cluster TiDB Binlog.

2. Edite o arquivo de configuração do Drainer para definir o Kafka como saída. Consulte Desenvolvimento personalizado para Kafka.Desenvolvimento Personalizado para Kafka

3. Verifique se o servidor do banco de dados TiDB consegue se conectar ao cluster Kafka.

4. Adicione os blocos CIDR dos servidores DTS à lista de permissões do banco de dados TiDB. Consulte Adicionar os blocos CIDR dos servidores DTS.

</details>

<details> <summary>Opção B: TiCDC</summary>

1. Instale o componente TiCDC. Use o TiUP para adicionar ou escalar horizontalmente o TiCDC no seu cluster TiDB existente. Consulte Implantar TiCDC.

2. Replicar dados incrementais para o Kafka usando tiup cdc cli changefeed create \ como o primeiro comando. Consulte Replicar dados para o Kafka.

3. Verifique se o servidor do banco de dados TiDB consegue se conectar ao cluster Kafka.

</details>

Etapa 1: Acessar a página Data Migration

Use um dos seguintes métodos:

Etapa 2: Configurar bancos de dados de origem e destino

1. Clique em Create Task.

2. Na página de configuração da tarefa, configure os bancos de dados de origem e destino.

Parâmetros do banco de dados de origem

Parâmetros do banco de dados de destino

Etapa 3: Testar conectividade

Na parte inferior da página, clique em Test Connectivity and Proceed. Na caixa de diálogo CIDR Blocks of DTS Servers, clique em Test Connectivity.

Certifique-se de que os blocos CIDR dos servidores DTS foram adicionados às configurações de segurança dos bancos de dados de origem e destino. Consulte Adicionar os blocos CIDR dos servidores DTS .

Etapa 4: Configurar objetos de migração

1. Na página Configure Objects, defina os seguintes parâmetros.

Tipos de migração e tratamento de conflitos

Seleção de objetos

Parâmetro	Descrição
Source Objects	Selecione as tabelas ou bancos de dados a serem migrados. Clique em para mover os objetos selecionados para Selected Objects.
Selected Objects	Clique com o botão direito em um objeto para renomeá-lo. Consulte Mapear o nome de um único objeto. Clique em Batch Edit para renomear vários objetos de uma vez. Consulte Mapear vários nomes de objetos simultaneamente. Clique com o botão direito em uma tabela para configurar uma condição de filtro WHERE. Nota Renomear um objeto pode impedir que objetos dependentes sejam migrados. Nota

1. Clique em Next: Advanced Settings.

Advanced settings

1. Clique em Next Step: Data Verification para configurar a verificação de dados. Consulte Configurar uma tarefa de verificação de dados.

Etapa 5: Executar a pré-verificação

1. Para visualizar os parâmetros da API desta tarefa, mova o ponteiro sobre Next: Save Task Settings and Precheck e clique em Preview OpenAPI parameters.

2. Clique em Next: Save Task Settings and Precheck.

O DTS executa uma pré-verificação antes de iniciar a migração. A tarefa só começa após a aprovação na pré-verificação.

Para itens de pré-verificação com falha, clique em View Details para diagnosticar o problema, resolvê-lo e, em seguida, execute a pré-verificação novamente.

Para itens de alerta: se o alerta não puder ser ignorado, corrija o problema e execute a pré-verificação novamente. Se o alerta puder ser ignorado, clique em Confirm Alert Details , depois clique em Ignore > OK > Precheck Again .

Etapa 6: Adquirir e iniciar a instância

1. Aguarde até que a Success Rate atinja 100%, então clique em Next: Purchase Instance.

2. Na página Purchase Instance, configure a classe da instância.

1. Leia e aceite os Data Transmission Service (Pay-as-you-go) Service Terms marcando a caixa de seleção.

2. Clique em Buy and Start, depois clique em OK.

A tarefa aparecerá na página Data Migration. Monitore o progresso dela nessa página.