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 |
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.
-
Prepare um cluster Kafka usando uma destas opções:
-
Cluster Kafka autogerenciado: Consulte a documentação do Apache Kafka. Defina
message.max.bytesereplica.fetch.max.bytesno broker, efetch.message.max.bytesno 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.
-
-
Crie um tópico no cluster Kafka ou na instância ApsaraMQ for Kafka.
ImportanteO tópico deve ter exatamente uma partição. O DTS lê dados incrementais apenas da partição com ID 0.
-
Implante o Pump e o Drainer. Para detalhes, consulte Implantação de cluster TiDB Binlog.
-
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.
-
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
-
Prepare um cluster Kafka usando uma destas opções:
-
Cluster Kafka autogerenciado: Consulte a documentação do Apache Kafka. Defina
message.max.bytesereplica.fetch.max.bytesno broker, efetch.message.max.bytesno 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.
-
-
Crie um tópico no cluster Kafka ou na instância ApsaraMQ for Kafka.
ImportanteO tópico deve ter exatamente uma partição. O DTS lê dados incrementais apenas da partição com ID 0.
-
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.
-
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_serverno 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:
-
Faça login no console do DTS.
-
No painel de navegação à esquerda, clique em Data Migration.
-
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.
-
Faça login no console do DMS.
-
Na barra de navegação superior, acesse Data + AI > DTS (DTS) > Data Migration.
-
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
-
Clique em Create Task.
-
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 |
| 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
-
Aguarde até que Success Rate chegue a 100% e clique em Next: Purchase Instance.
-
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. -
Leia e aceite os Data Transmission Service (Pay-as-you-go) Service Terms marcando a caixa de seleção.
-
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:
-
Pare as gravações no banco de dados TiDB de origem.
-
Aguarde até que a latência da migração incremental chegue a 0 e a tarefa processe todas as alterações restantes.
-
Atualize as strings de conexão da sua aplicação para apontar para a instância do ApsaraDB RDS for MySQL.
-
Execute
ANALYZE TABLE <table_name>nas tabelas principais para verificar a integridade dos dados. -
Pare ou libere a tarefa de migração do DTS.