Data Transmission Service:Migrar dados do RDS MySQL para um banco de dados Doris auto-gerenciado

Permissões necessárias

Para criar contas e conceder permissões:

• RDS for MySQL: consulte Create an account e Modify the permissions of an account.

• Doris: consulte Authentication and authorization.

Requisitos de binary log (apenas para migração incremental)

Para migração incremental, a instância source do RDS for MySQL deve ter o binary log configurado corretamente:

• binlog_format = ROW

• binlog_row_image = FULL

• Retenção local de binary log: mínimo de 3 dias (recomendado: 7 dias)

Se o source for um banco de dados MySQL auto-gerenciado, os binary logs locais devem ser retidos por pelo menos 7 dias.

Caso alguma configuração esteja incorreta, a pré-verificação falhará e a migração não poderá ser iniciada.

Para instruções sobre como definir o período de retenção do binary log no RDS for MySQL, consulte Delete local logs automatically .

Limitações do banco de dados source

• O servidor que hospeda o banco de dados source precisa ter largura de banda de saída suficiente. Largura de banda baixa reduz a velocidade da migração.

• Ao realizar migração incremental em um cluster MySQL auto-gerenciado com dois primários (onde cada nó é primário do outro), ative o parâmetro log_slave_updates no source.

• Para migrar tabelas com edições no nível de coluna (como mapeamento de nomes de colunas), uma única tarefa suporta no máximo 1.000 tabelas. Em migrações maiores, divida as tabelas em várias tarefas ou migre o banco de dados inteiro.

• Não execute operações DDL que alterem o schema do banco de dados ou da tabela durante a migração de schema ou a migração completa de dados. Essa ação causa falha na tarefa.

• Se executar apenas a migração completa de dados (sem incremental), não grave novos dados no source durante a migração.

• Dados gerados por operações não registradas nos binary logs — como restauração de backup físico ou operações em cascata — não são migrados.

• Se o source for MySQL 8.0.23 ou posterior e os dados contiverem colunas invisíveis, essas colunas não serão migradas, o que pode causar perda de dados. Execute ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; para tornar as colunas invisíveis visíveis antes da migração. Tabelas sem chave primária geram automaticamente uma chave primária invisível — você também deve tornar essa chave primária invisível visível. Para mais informações, consulte Generated Invisible Primary Keys.

• Instâncias do RDS for MySQL com o recurso always-confidential ativado não suportam migração completa de dados. Instâncias com Transparent Data Encryption (TDE) ativado suportam todos os tipos de migração.

Limitações do destino (Doris)

• O DTS só consegue gravar em tabelas que utilizam o modelo Unique Key ou modelo Duplicate Key no Doris.

• Quando uma tabela de destino usa o modelo Duplicate Key, o DTS converte instruções UPDATE e DELETE em instruções INSERT. Linhas duplicadas podem surgir se a tarefa de migração for repetida, reiniciada ou se múltiplas operações DML tiverem como alvo o mesmo registro entre sincronizações. Utilize as colunas adicionais _is_deleted, _version e _record_id para deduplicação. Consulte Additional column information para detalhes.

• O único parâmetro de tabela configurável no DTS é bucket_count (número de buckets). O valor deve ser um número inteiro positivo; o padrão é auto.

• Não crie um novo cluster no banco de dados Doris de destino durante a migração. Se a tarefa falhar por esse motivo, reinicie a instância de migração.

• Não adicione nós Backend (BE) ao cluster Doris durante a migração. Se a tarefa falhar por esse motivo, reinicie a instância de migração.

• O Doris aceita apenas nomes de bancos de dados e tabelas que começam com uma letra. Use o mapeamento de nomes de objetos para renomear quaisquer objetos que não comecem com uma letra.

• Se algum nome de banco de dados, tabela ou coluna contiver caracteres chineses, use o mapeamento de nomes de objetos para renomeá-lo (por exemplo, para um nome em inglês). Caso contrário, a tarefa poderá falhar.

• Evite operações DDL que modifiquem várias colunas simultaneamente ou que modifiquem a mesma tabela em rápida sucessão.

• Em cenários de mesclagem de várias tabelas (várias tabelas source mescladas em uma tabela de destino), as tabelas source devem ter schemas idênticos.

• O tipo VARCHAR(M) do MySQL usa comprimento de caracteres (M); já o VARCHAR(N) do Doris usa comprimento de bytes (N). Se você pular a migração de schema e criar as tabelas do Doris manualmente, defina o comprimento VARCHAR do Doris como quatro vezes o comprimento VARCHAR do MySQL.

• Ao usar o Data Management (DMS) ou gh-ost para DDL online no source, o DTS migra apenas as instruções DDL originais, e não os dados da tabela temporária. Isso pode causar bloqueio de tabelas no destino. O pt-online-schema-change não é suportado para DDL online no source — seu uso pode resultar em perda de dados ou falha na tarefa.

• Não utilize ferramentas como pt-online-schema-change nos objetos de migração do banco de dados source durante a migração.

• A migração completa de dados usa operações INSERT concorrentes, o que causa fragmentação de tabelas. Após a migração completa, as tabelas de destino podem ocupar mais armazenamento do que no source.

• Se outra origem gravar no banco de dados de destino durante a migração, poderá ocorrer inconsistência de dados.

Comportamento da migração incremental

Por padrão, o DTS processa em lote as gravações incrementais no destino no máximo uma vez a cada 5 segundos por objeto de sincronização. Isso resulta em uma latência de sincronização normal de até 10 segundos.

Para reduzir a latência, ajuste o parâmetro selectdb.reservoir.timeout.milliseconds da instância DTS no console. Faixa válida: 1.000–10.000 milissegundos.

Intervalos de lote menores aumentam a frequência de gravação no destino, o que eleva a carga e o tempo de resposta (RT) no Doris, podendo aumentar a latência geral de sincronização. Faça ajustes conforme a capacidade de carga do destino.

Recomendações de desempenho

Antes de iniciar a migração, verifique se a carga de CPU dos bancos de dados source e de destino está abaixo de 30%. Execute a migração fora dos horários de pico para minimizar o impacto nas cargas de trabalho de produção.

Casos especiais

Se o source for um banco de dados MySQL auto-gerenciado:

• Um failover primário/secundário no source causa falha na tarefa de migração.

• O DTS calcula a latência comparando o timestamp UNIX do último registro migrado com a hora atual. Se nenhuma operação DML for executada no source por um longo período, a latência exibida pode ser imprecisa. Execute uma operação DML no source para atualizá-la ou crie uma tabela de heartbeat com gravações a cada segundo.

• Periodicamente, o DTS executa CREATE DATABASE IF NOT EXISTS no source para avançar o offset do binary log.

• Para Amazon Aurora MySQL ou outras instâncias MySQL em cluster, confirme se o nome de domínio ou endereço IP configurado na tarefa sempre resolve para o nó de leitura/gravação (RW).

Se o source for uma instância do RDS for MySQL:

• Instâncias somente leitura do RDS for MySQL (como instâncias somente leitura do RDS for MySQL 5.6) não registram logs de transação e não podem ser usadas como source para migração incremental.

• Periodicamente, o DTS executa CREATE DATABASE IF NOT EXISTS no source para avançar o offset do binary log.

Etapa 1: Abrir a página Data Migration

Utilize um dos métodos a seguir para abrir a página Data Migration.

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 (DMS)

O caminho exato de navegação pode variar conforme o modo e o layout do console DMS. Para detalhes, consulte Simple mode e Customize the layout and style of the DMS console .

1. Faça login no console do DMS.

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

3. Na lista suspensa ao lado de Data Migration Tasks, selecione a região.

Etapa 2: Configurar os bancos de dados source e de destino

Clique em Create Task para abrir a página de configuração da tarefa e configure os parâmetros abaixo.

Etapa 3: Testar a 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 Confirm authorization and test link.

Certifique-se de que os blocos CIDR dos servidores DTS possam ser adicionados (automaticamente ou manualmente) às configurações de segurança tanto do source quanto do destino. Para detalhes, consulte Add DTS server IP addresses to a whitelist.

Etapa 4: Selecionar objetos e tipos de migração

Na página Configure Objects, defina as seguintes configurações.

Tipos de migração

Modo de processamento de tabelas conflitantes

Capitalização de nomes de objetos na instância de destino

Por padrão, aplica-se a DTS default policy. Ajuste se precisar que a capitalização dos nomes dos objetos corresponda ao source ou ao destino. Consulte Specify the capitalization of object names in the destination instance.

Seleção e configuração de objetos de migração

1. Em Source Objects, selecione os bancos de dados ou tabelas a serem migrados e clique em para movê-los para Selected Objects.

2. Em Selected Objects, clique com o botão direito em qualquer objeto para:

   • Mapear seu nome para um nome diferente no destino

   • Selecionar operações SQL incrementais específicas no nível do banco de dados ou da tabela

   • Definir condições WHERE para filtrar linhas (Set filter conditions)

   • Definir o parâmetro bucket_count (se a migração de schema estiver selecionada): clique com o botão direito em uma tabela, vá para Parameter Settings, defina Enable Parameter Settings como Yes, insira o valor e clique em OK

O uso de mapeamento de nomes de objetos pode causar falha na migração de objetos dependentes.

Etapa 5: Configurar definições avançadas

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

Etapa 6: (Opcional) Configurar campos de banco de dados e tabelas

Clique em Next: Configure Database and Table Fields para definir a Primary Key Column, Distribution Key e Engine das tabelas de destino.

Esta etapa está disponível apenas se Schema Migration estiver selecionado.

Defina Definition Status como All para visualizar e modificar todas as tabelas.

Primary Key Column suporta chaves primárias compostas. Selecione uma ou mais colunas em Primary Key Column como a Distribution Key .

Para tabelas sem chave primária ou restrição UNIQUE, defina Engine como duplicate .

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

Clique em Next: Save Task Settings and Precheck.

Para visualizar os parâmetros da OpenAPI antes de salvar, passe o mouse sobre Next: Save Task Settings and Precheck e clique em Preview OpenAPI parameters.

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.

• Se algum item falhar, clique em View Details ao lado do item com falha, resolva o problema e clique em Precheck Again.

• Se aparecer um alerta não crítico que possa ser ignorado com segurança, clique em Confirm Alert Details > Ignore > OK > Precheck Again. Ignorar alertas pode resultar em inconsistência de dados.

Etapa 8: Adquirir e iniciar a instância

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

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

   Parâmetro	Descrição
   Resource Group	Grupo de recursos para a instância de migração (padrão: default resource group). Consulte What is Resource Management?
   Instance Class	Determina a velocidade da migração. Escolha conforme suas necessidades. Consulte Instance classes of data migration instances.

3. Leia e aceite os Data Transmission Service (Pay-as-you-go) Service Terms.

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

Verificar o status da migração

Visualize o progresso da tarefa na página Data Migration.

• Apenas migração completa: a tarefa para automaticamente quando concluída. O status mostra Completed.

• Migração completa + incremental: a fase incremental é executada continuamente. O status mostra Running.

Se uma instância falhar, o suporte do DTS tentará a recuperação dentro de 8 horas. As operações de recuperação podem incluir reiniciar a instância e ajustar parâmetros da instância DTS (não parâmetros do banco de dados). Para detalhes, consulte Modify instance parameters .