Todos os produtos
Search
Central de documentação

Data Transmission Service:Migrar dados de um banco de dados TiDB autogerenciado para uma instância do ApsaraDB RDS for MySQL

Última atualização: Jun 27, 2026

Este tópico descreve como usar o Data Transmission Service (DTS) para migrar dados de um banco de dados TiDB autogerenciado para uma instância do ApsaraDB RDS for MySQL.

Escolha seu caminho de migração:

Caminho Etapas Quando usar
Somente migração completa Pré-requisitos → Procedimento Migração única com uma breve janela de manutenção
Migração completa + incremental Pré-requisitos → Preparações → Procedimento Migração sem tempo de inatividade; mantenha o banco de dados de origem ativo durante a migração
Importante

Tabelas sem chave primária ou restrição UNIQUE podem resultar em registros duplicados no banco de dados de destino. Verifique se todas as tabelas a serem migradas têm restrições PRIMARY KEY ou UNIQUE antes de começar.

Pré-requisitos

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

  • Uma instância do ApsaraDB RDS for MySQL com espaço de armazenamento disponível maior que o tamanho total dos dados no banco de dados TiDB de origem. Para detalhes, consulte Criar uma instância do ApsaraDB RDS for MySQL.

  • (Somente para migração completa + incremental) Concluída a seção Preparações para configurar um cluster Kafka e o TiDB Binlog ou TiCDC para captura de dados incrementais.

Preparações (somente para migração incremental)

Ignore esta seção se precisar apenas de migração completa de dados.

O DTS lê dados incrementais do TiDB por meio de um pipeline baseado em Kafka. O DTS lê exclusivamente da partição 0 do tópico Kafka, portanto, o tópico deve ter exatamente uma partição. Antes de criar a tarefa do DTS, configure esse pipeline usando um dos métodos a seguir.

Método 1: TiDB Binlog

Implante o servidor do banco de dados de origem, o Pump, o Drainer e o cluster Kafka na mesma rede interna para minimizar a latência de rede.
  1. Prepare um cluster Kafka usando uma destas opções:

    • Cluster Kafka autogerenciado: Consulte a documentação do Apache Kafka. Defina message.max.bytes e replica.fetch.max.bytes no broker, e fetch.message.max.bytes no consumidor com valores grandes o suficiente para processar o volume de log binário do TiDB. Para detalhes de configuração, consulte CONFIGURATION.

    • Instância ApsaraMQ for Kafka: Consulte Visão geral de introdução. Implante a instância no mesmo virtual private cloud (VPC) que o servidor do banco de dados de origem.

  2. Crie um tópico no cluster Kafka ou na instância ApsaraMQ for Kafka.

    Importante

    O tópico deve ter exatamente uma partição. O DTS lê dados incrementais apenas da partição com ID 0.

  3. Implante o Pump e o Drainer. Para detalhes, consulte Implantação de cluster TiDB Binlog.

  4. Edite o arquivo de configuração do Drainer para apontar para seu cluster Kafka. Para detalhes, consulte Guia do usuário do cliente consumidor Binlog.

    Verifique se o servidor do banco de dados TiDB pode se conectar ao cluster Kafka.
  5. Adicione os blocos CIDR dos servidores DTS à lista de permissões do banco de dados TiDB. Para detalhes, consulte Adicionar os blocos CIDR dos servidores DTS.

Método 2: TiCDC

  1. Prepare um cluster Kafka usando uma destas opções:

    • Cluster Kafka autogerenciado: Consulte a documentação do Apache Kafka. Defina message.max.bytes e replica.fetch.max.bytes no broker, e fetch.message.max.bytes no consumidor com valores grandes o suficiente para processar o volume de log binário do TiDB. Para detalhes de configuração, consulte CONFIGURATION.

    • Instância ApsaraMQ for Kafka: Consulte Visão geral de introdução. Implante a instância no mesmo VPC que o servidor do banco de dados de origem.

  2. Crie um tópico no cluster Kafka ou na instância ApsaraMQ for Kafka.

    Importante

    O tópico deve ter exatamente uma partição. O DTS lê dados incrementais apenas da partição com ID 0.

  3. Instale o TiCDC. Recomendamos usar o TiUP para adicionar um novo nó TiCDC ou expandir o nó TiCDC existente no cluster TiDB. Para detalhes, consulte Implantar e manter o TiCDC.

  4. Replique os dados incrementais do banco de dados TiDB de origem para o Kafka. Recomendamos usar tiup cdc cli changefeed create \ na primeira linha de comando. Para detalhes, consulte Replicar dados para o Kafka.

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

Permissões necessárias

Banco de dados Permissões necessárias
Banco de dados TiDB SELECT nos objetos a migrar; SHOW VIEW
Instância do ApsaraDB RDS for MySQL Permissões de leitura e gravação no banco de dados de destino

Para obter ajuda sobre como criar e configurar contas, consulte Criar uma conta e Modificar permissões de conta.

Faturamento

Tipo de migração Taxa de configuração da instância Taxa de tráfego de Internet
Migração de esquema + migração completa de dados Gratuito Cobrado quando Access Method está definido como Public IP Address. Consulte Visão geral do faturamento.
Migração incremental de dados Cobrado. Consulte Visão geral do faturamento.

Operações SQL compatíveis com migração incremental

Tipo de operação Instruções SQL
DML INSERT, UPDATE, DELETE
DDL CREATE TABLE, DROP TABLE, ALTER TABLE, RENAME TABLE, TRUNCATE TABLE, CREATE VIEW, DROP VIEW, ALTER VIEW

Notas de uso

Limites do banco de dados de origem:

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

  • As tabelas devem ter restrições PRIMARY KEY ou UNIQUE com todos os campos únicos. Tabelas sem essas restrições podem causar registros duplicados no destino.

  • Ao migrar com renomeação de tabela ou coluna, uma única tarefa suporta até 1.000 tabelas. Para mais de 1.000 tabelas, execute várias tarefas em lotes ou migre no nível do banco de dados.

  • A migração incremental de dados requer um cluster Kafka com TiDB Binlog ou TiCDC configurado (consulte Preparações).

Migração completa de dados:

  • Execute migrações fora dos horários de pico, quando a carga de CPU em ambos os bancos de dados estiver abaixo de 30%. O DTS usa recursos de leitura e gravação em ambos os bancos de dados durante a migração completa.

  • Operações INSERT simultâneas durante a migração completa causam fragmentação de tabelas no destino. Espere que o espaço de tabelas de destino seja maior que o de origem após a conclusão da migração.

  • Evite gravar dados de outras fontes no destino durante a migração para prevenir inconsistência de dados.

Migração incremental de dados:

  • Após criar a tarefa, execute operações no banco de dados de origem ou insira dados de teste prontamente. Isso atualiza as informações de offset e evita falhas na tarefa por latência excessiva.

  • O DTS lê dados incrementais apenas da partição 0 do tópico Kafka.

Considerações sobre tipos de dados e conjunto de caracteres:

  • Dados contendo caracteres raros ou emojis (caracteres de 4 bytes) exigem que as tabelas de destino usem o conjunto de caracteres UTF8mb4. Se você usar o recurso de migração de esquema, defina o parâmetro character_set_server no banco de dados de destino como UTF8mb4.

  • Os nomes de colunas no MySQL não diferenciam maiúsculas de minúsculas. Gravar nomes de colunas que diferem apenas na capitalização na mesma tabela de destino pode produzir resultados inesperados.

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

Após a migração:

  • Quando o campo Status da tarefa exibir Completed, execute ANALYZE TABLE <table_name> para verificar se os dados foram gravados no disco. Uma alternância de HA no banco de dados MySQL de destino pode fazer com que os dados existam apenas na memória, levando à perda de dados.

  • O DTS tenta retomar tarefas com falha por até 7 dias. Antes de migrar cargas de trabalho para o banco de dados de destino, pare ou libere quaisquer tarefas com falha, ou execute REVOKE para remover as permissões de gravação do DTS no destino. Caso contrário, uma tarefa retomada pode sobrescrever os dados do destino com os dados da origem.

  • Instruções DDL que falham no destino não interrompem a tarefa do DTS. Visualize as instruções DDL com falha nos logs da tarefa. Para detalhes, consulte Visualizar logs de tarefas.

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

  • Se o nome do banco de dados de origem não estiver em conformidade com as convenções de nomenclatura do ApsaraDB RDS for MySQL, crie o banco de dados de destino primeiro e use o recurso de mapeamento de nomes de objetos para renomeá-lo durante a configuração da tarefa. Para detalhes, consulte Gerenciar bancos de dados e Mapear nomes de objetos.

Configurar e executar a tarefa de migração

Etapa 1: Acesse a página de migração de dados

Use um destes consoles:

Console do DTS:

  1. Faça login no console do DTS.

  2. No painel de navegação à esquerda, clique em Data Migration.

  3. No canto superior esquerdo, selecione a região onde a instância de migração reside.

Console do Data Management Service (DMS):

As etapas reais podem variar com base no modo e layout do console DMS. Para detalhes, consulte Modo simples e Personalizar o layout e o estilo do console DMS.
  1. Faça login no console do DMS.

  2. Na barra de navegação superior, acesse Data + AI > DTS (DTS) > Data Migration.

  3. Na lista suspensa ao lado de Data Migration Tasks, selecione a região onde a instância de migração reside.

Etapa 2: Crie a tarefa e configure os bancos de dados de origem e destino

  1. Clique em Create Task.

  2. Configure os bancos de dados de origem e destino usando os seguintes parâmetros:

Configurações da tarefa:

Parâmetro Descrição
Task Name Um nome para a tarefa do DTS. O DTS gera um nome automaticamente. Especifique um nome descritivo para identificar a tarefa facilmente. O nome não precisa ser único.

Banco de dados de origem:

Parâmetro Descrição
Select Existing Connection Se a instância TiDB estiver registrada no DTS, selecione-a na lista e o DTS preencherá os parâmetros de conexão automaticamente. Caso contrário, configure os parâmetros abaixo. No console DMS, use a lista Select a DMS database instance.
Database Type Selecione TiDB.
Access Method Selecione o método de acesso com base no local onde o TiDB está implantado. Este exemplo usa Self-managed Database on ECS. Para outros métodos de acesso, conclua a configuração de ambiente necessária primeiro. Consulte Visão geral de preparação.
Instance Region A região onde o banco de dados TiDB reside.
ECS Instance ID O ID da instância ECS que hospeda o banco de dados TiDB.
Port Number A porta de serviço TiDB. Padrão: 4000.
Database Account A conta TiDB. Consulte Permissões necessárias para as permissões exigidas.
Database Password A senha da conta TiDB.
Migrate Incremental Data Selecione Yes para ativar a migração incremental de dados e insira as informações do cluster Kafka na seção Parâmetros do cluster Kafka. Selecione No para somente migração completa.

Banco de dados de destino:

Parâmetro Descrição
Select Existing Connection Se a instância RDS estiver registrada no DTS, selecione-a na lista. Caso contrário, configure os parâmetros abaixo. No console DMS, use a lista Select a DMS database instance.
Database Type Selecione MySQL.
Access Method Selecione Alibaba Cloud Instance.
Instance Region A região onde a instância do ApsaraDB RDS for MySQL de destino reside.
Replicate Data Across Alibaba Cloud Accounts Selecione No para migração na mesma conta.
RDS Instance ID O ID da instância do ApsaraDB RDS for MySQL de destino.
Database Account A conta do banco de dados de destino. Consulte Permissões necessárias.
Database Password A senha da conta do banco de dados de destino.
Encryption Selecione Non-encrypted ou SSL-encrypted. Para usar a criptografia SSL, ative a criptografia SSL na instância RDS antes de configurar a tarefa. Consulte Usar um certificado de nuvem para ativar a criptografia SSL.

Etapa 3: Teste a conectividade

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

Os blocos CIDR dos servidores DTS devem ser adicionados (automaticamente ou manualmente) às configurações de segurança dos bancos de dados de origem e destino. Para detalhes, consulte Adicionar os blocos CIDR dos servidores DTS.

Etapa 4: Configure os objetos a migrar

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

Parâmetro Descrição
Migration Types Selecione os tipos de migração com base no seu caminho: <br>- Schema Migration + Full Data Migration: somente migração completa.<br>- Schema Migration + Full Data Migration + Incremental Data Migration: migração completa + incremental para migração sem tempo de inatividade.<br><br>
Nota

Se você ignorar Schema Migration, crie o banco de dados e as tabelas de destino antes de iniciar a tarefa e ative o mapeamento de nomes de objetos em Selected Objects. Se você ignorar Incremental Data Migration, pare de gravar no banco de dados de origem durante a migração para manter a consistência dos dados.

Processing Mode of Conflicting Tables Precheck and Report Errors (recomendado): reprovação no pré-verificação se houver tabelas com nomes idênticos na origem e no destino. Use o mapeamento de nomes de objetos para renomear tabelas conflitantes. Consulte Mapear nomes de objetos. <br><br>Ignore Errors and Proceed: ignora o pré-verificação para nomes de tabelas idênticos. Use com cuidado — isso pode causar inconsistência de dados. Durante a migração completa, os registros existentes no destino são mantidos. Durante a migração incremental, os registros existentes são sobrescritos. Se os esquemas forem diferentes, apenas colunas específicas são migradas ou a tarefa pode falhar.
Capitalization of Object Names in Destination Instance Controla as maiúsculas e minúsculas dos nomes de banco de dados, tabela e coluna no destino. DTS default policy é selecionado por padrão. Consulte Especificar as maiúsculas e minúsculas dos nomes de objetos.
Source Objects Selecione tabelas ou bancos de dados na seção Source Objects e clique em seta para a direita para adicioná-los a Selected Objects.
Selected Objects - Para renomear um único objeto, clique com o botão direito nele em Selected Objects. Consulte Mapear o nome de um único objeto.<br>- Para renomear vários objetos de uma vez, clique em Batch Edit. Consulte Mapear vários nomes de objetos de uma vez.<br>- Para filtrar linhas, clique com o botão direito em uma tabela e especifique as condições de filtro.<br><br>
Nota

Renomear um objeto pode afetar outros objetos que dependem dele.

Etapa 5: Configure as definições avançadas

Clique em Next: Advanced Settings e configure os seguintes parâmetros:

Parâmetro Descrição
Retry Time for Failed Connections Por quanto tempo o DTS tenta novamente conexões com falha após o início da tarefa. Valores válidos: 10–1.440 minutos. Padrão: 720. Defina pelo menos 30 minutos. O DTS retoma a tarefa se a reconexão for bem-sucedida dentro dessa janela; caso contrário, a tarefa falhará.<br><br>
Nota

Se várias tarefas compartilharem o mesmo banco de dados de origem ou destino, o tempo de nova tentativa definido mais recentemente se aplica a todas elas. O DTS cobra pelo uso da instância durante as novas tentativas.

Retry Time for Other Issues Por quanto tempo o DTS tenta novamente operações DDL ou DML com falha. Valores válidos: 1–1.440 minutos. Padrão: 10. Defina pelo menos 10 minutos. Esse valor deve ser menor que Retry Time for Failed Connections.
Enable Throttling for Full Data Migration Limita o uso de recursos durante a migração completa para reduzir a carga nos bancos de dados. Configure Queries per second (QPS) to the source database, RPS of Full Data Migration e Data migration speed for full migration (MB/s). Disponível somente quando Full Data Migration estiver selecionado.
Enable Throttling for Incremental Data Migration Limita o uso de recursos durante a migração incremental. Configure RPS of Incremental Data Migration e Data migration speed for incremental migration (MB/s). Disponível somente quando Incremental Data Migration estiver selecionado.
Environment Tag Uma tag opcional para identificar a instância DTS.
Configure ETL Ative o recurso de extração, transformação e carregamento (ETL) para transformar dados durante a migração. Selecione Yes e insira instruções de processamento no editor de código. Consulte O que é ETL? e Configurar ETL.
Monitoring and Alerting Configure alertas para falha de tarefa ou latência de migração excedendo um limiar. Selecione Yes e configure o limiar de alerta e as configurações de notificação. Consulte Configurar monitoramento e alertas.

Etapa 6: Configure a verificação de dados (opcional)

Clique em Next Step: Data Verification para configurar uma tarefa de verificação de dados. Para detalhes, consulte Configurar uma tarefa de verificação de dados.

Etapa 7: Salve as configurações e execute o pré-verificação

  • Para visualizar os parâmetros da API para configurar esta tarefa de forma programática, passe o cursor sobre Next: Save Task Settings and Precheck e clique em Preview OpenAPI parameters.

  • Para continuar, clique em Next: Save Task Settings and Precheck.

O DTS executa um pré-verificação antes do início da migração. A tarefa não pode iniciar até que o pré-verificação seja aprovado.
Se o pré-verificação falhar, clique em View Details ao lado do item com falha, resolva o problema e clique em Precheck Again.
Para alertas de pré-verificação: se o alerta não puder ser ignorado, corrija o problema e execute novamente o pré-verificação. Se puder ser ignorado, clique em Confirm Alert Details, depois Ignore, depois OK e depois Precheck Again. Ignorar alertas pode causar inconsistência de dados.

Etapa 8: Adquira a instância e inicie a migração

  1. Aguarde até que Success Rate chegue a 100% e clique em Next: Purchase Instance.

  2. Na página Purchase Instance, configure o seguinte:

    Parâmetro Descrição
    Resource Group O grupo de recursos para a instância de migração. Padrão: default resource group. Consulte O que é o Gerenciamento de Recursos?
    Instance Class A velocidade de migração depende da classe da instância. Consulte Classes de instância de instâncias de migração de dados para selecionar uma classe adequada à sua carga de trabalho.
  3. Leia e aceite os Data Transmission Service (Pay-as-you-go) Service Terms marcando a caixa de seleção.

  4. Clique em Buy and Start e, em seguida, clique em OK na caixa de diálogo de confirmação.

Monitore a tarefa na página Data Migration:

  • Somente migração completa: A tarefa para automaticamente quando concluída. O campo Status exibe Completed.

  • Migração completa + incremental: A tarefa é executada continuamente. O campo Status exibe Running.

Parâmetros do cluster Kafka

Quando Migrate Incremental Data estiver definido como Yes, configure o cluster Kafka na seção de banco de dados de origem:

Parâmetro Descrição
Kafka Cluster Type O local de implantação do cluster Kafka. Este exemplo usa Self-managed Database on ECS. Se você selecionar Express Connect, VPN Gateway, or Smart Access Gateway, selecione também um VPC em Connected VPC e especifique Domain Name or IP.
Kafka Data Source Component Selecione com base no método usado em Preparações: Use the default binlog format of the TiDB database. (TiDB Binlog) ou Use the TiCDC Canal-JSON format. (TiCDC).
ECS Instance ID O ID da instância ECS que hospeda o cluster Kafka.
Port Number A porta de serviço do Kafka.
Kafka Cluster Account O nome de usuário do Kafka. Deixe em branco se a autenticação não estiver ativada.
Kafka Cluster Password A senha do Kafka. Deixe em branco se a autenticação não estiver ativada.
Kafka Version A versão do Kafka. Se a versão for 1.0 ou posterior, selecione 1.0.
Encryption Selecione Non-encrypted ou SCRAM-SHA-256 com base em seus requisitos de segurança.
Topic O tópico que recebe dados incrementais. O tópico deve ter apenas uma partição.

Próximas etapas

Após o status da tarefa de migração exibir Completed ou a latência da migração incremental chegar a zero, migre sua aplicação para o banco de dados de destino:

  1. Pare as gravações no banco de dados TiDB de origem.

  2. Aguarde até que a latência da migração incremental chegue a 0 e a tarefa processe todas as alterações restantes.

  3. Atualize as strings de conexão da sua aplicação para apontar para a instância do ApsaraDB RDS for MySQL.

  4. Execute ANALYZE TABLE <table_name> nas tabelas principais para verificar a integridade dos dados.

  5. Pare ou libere a tarefa de migração do DTS.