Data Transmission Service:Migrar dados de uma instância ApsaraDB RDS for MySQL para um cluster ApsaraDB for ClickHouse

Cluster de destino

• O cluster de destino ApsaraDB for ClickHouse deve executar a versão 20.8 ou posterior. Consulte Criar um cluster.

• O espaço de armazenamento no cluster de destino deve exceder o armazenamento utilizado pela instância RDS MySQL de origem.

Permissões da conta do banco de dados de origem

A conta do banco de dados de origem precisa ter permissões de leitura nos objetos a serem migrados. Caso a conta não tenha sido criada pelo console RDS, conceda as seguintes permissões manualmente:

GRANT REPLICATION CLIENT, REPLICATION SLAVE, SHOW VIEW, SELECT ON *.* TO '<account>'@'%';

Consulte Criar uma conta e Modificar permissões da conta.

Permissões da conta do cluster de destino

Requisitos de log binário (apenas para migração incremental)

Se você planeja incluir a migração incremental de dados, configure os seguintes parâmetros na instância MySQL de origem.

Ativar retenção de log binário

O período mínimo de retenção depende do tipo de origem:

• ApsaraDB RDS for MySQL: Os logs binários devem ser retidos por pelo menos 3 dias (recomenda-se 7 dias).

• MySQL autogerenciado: Os logs binários devem ser retidos por pelo menos 7 dias.

Logs retidos por um período inferior ao mínimo necessário podem causar falha na tarefa de migração ou resultar em perda de dados. Para definir o período de retenção de uma instância RDS MySQL, consulte Configurar parâmetros para exclusão automática de arquivos de log binário de uma instância RDS.

Configurar formato do log binário

Defina os seguintes parâmetros na instância MySQL de origem:

Essas configurações são essenciais para que o DTS leia dados de alterações no nível de linha. Se não forem definidas corretamente, a pré-verificação falhará e a tarefa de migração não poderá ser iniciada.

Se a origem for um banco de dados MySQL autogerenciado implantado em um cluster com dois primários, defina também log_slave_updates = ON para que o DTS possa obter todos os logs binários.

Restrições do banco de dados de origem

• Limite de migração no nível de tabela: Uma única tarefa de migração suporta no máximo 1.000 tabelas quando o mapeamento de nomes de objetos é utilizado. Se ultrapassar esse limite, divida as tabelas em várias tarefas ou migre o banco de dados inteiro.

• Colunas invisíveis (MySQL 8.0.23 e posterior): O DTS não consegue ler colunas invisíveis, o que causa perda de dados. Para tornar uma coluna visível, execute ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;. Tabelas sem chaves primárias explícitas geram automaticamente chaves primárias invisíveis — torne-as visíveis também. Consulte Colunas Invisíveis e Chaves Primárias Invisíveis Geradas.

• RDS MySQL V5.6 somente leitura: Este tipo de instância não registra logs de transação e não pode ser usado como origem para migração incremental.

• Instâncias com EncDB ativado: Não há suporte para migração completa de dados. Instâncias com Transparent Data Encryption (TDE) ativado suportam migração de esquema, migração completa de dados e migração incremental de dados.

• Restrições de DDL durante a migração: Não execute instruções DDL enquanto a migração de esquema ou a migração completa de dados estiver em andamento. Para migrações apenas completas, não grave no banco de dados de origem durante o processo.

• Restaurações de backup físico e operações em cascata: Dados de alteração gerados por restaurações de backup físico ou operações em cascata na origem não são registrados nem migrados para o destino enquanto a instância de migração estiver em execução. Se isso ocorrer, execute a migração completa de dados novamente, desde que sua operação não seja afetada.

Outras restrições

• Não há suporte para migração de INDEX, PARTITION, VIEW, PROCEDURE, FUNCTION, TRIGGER e chaves estrangeiras.

• A operação RENAME TABLE não pode ser migrada.

• Caso o banco de dados de origem tenha operações de alteração DDL online no modo de tabela temporária, como em cenários de mesclagem de múltiplas tabelas, pode ocorrer perda de dados no banco de destino ou falha na instância de migração.

• Se a origem contiver alterações DDL online realizadas com pt-online-schema-change, pode haver perda de dados ou falha na migração. Ao migrar uma ou mais tabelas em vez de um banco de dados inteiro, não use pt-online-schema-change para executar operações DDL online nos objetos de migração na origem — caso contrário, a migração falhará. Alterações DDL online realizadas com DMS ou gh-ost são suportadas — o DTS migra a instrução DDL original sem copiar dados de tabelas temporárias, mas isso pode causar bloqueio de tabelas no destino. É possível usar o Data Management (DMS) para realizar operações DDL online.

• Instruções DDL na origem que não seguirem a sintaxe padrão do MySQL podem causar falha na tarefa de migração ou perda de dados.

• A quantidade de bancos de dados a serem migrados não deve exceder 256 (limite do ClickHouse).

• Os nomes de bancos de dados, tabelas e colunas devem obedecer às Convenções de nomenclatura do ApsaraDB for ClickHouse.

• Durante a migração de esquema, o DTS adiciona os campos _sign, _is_deleted e _version às tabelas de destino. Se pular a migração de esquema, crie as tabelas de destino manualmente e inclua esses campos. Consulte Apêndice: informações de tabela e campo.

• Não grave dados de fontes externas ao DTS no banco de dados de destino enquanto a migração estiver em execução.

• Se uma tarefa do DTS falhar, o suporte técnico tentará restaurá-la em até 8 horas. Durante a restauração, a tarefa pode ser reiniciada e seus parâmetros modificados. Nota: apenas os parâmetros da tarefa DTS podem ser alterados — os parâmetros dos bancos de dados permanecem inalterados. Os parâmetros passíveis de modificação incluem, entre outros, aqueles descritos na seção Modificar parâmetros da instância.

Restrições específicas do ClickHouse

• Intervalo de dados de tipo temporal: Os tipos de tempo do ClickHouse possuem limites de intervalo. Dados de origem fora desses intervalos serão gravados incorretamente. Consulte Apêndice: informações de tempo.

• Chave de partição: Não pode ser um campo anulável. Tipos suportados: BIGINT, INT, TIMESTAMP, DATETIME, DATE.

• Máximo de bancos de dados: 256.

Casos especiais

Origens MySQL autogerenciadas

• A tarefa falhará se você realizar um failover primário/secundário no banco de dados de origem durante a execução da migração.

• O DTS calcula a latência da migração com base no timestamp dos últimos dados migrados no destino e no timestamp atual na origem. Se nenhuma operação DML for executada na origem por um longo período, a latência pode ficar imprecisa. Para atualizar a latência, execute uma operação DML na origem. Se selecionar um banco de dados inteiro como objeto de migração, crie uma tabela de heartbeat atualizada a cada segundo.

• Periodicamente, o DTS executa CREATE DATABASE IF NOT EXISTS \ test\`` no banco de dados de origem para avançar a posição do arquivo de log binário.

Origens ApsaraDB RDS for MySQL

• Na migração incremental de dados, uma instância ApsaraDB RDS for MySQL V5.6 somente leitura não pode ser usada como banco de dados de origem.

• Periodicamente, o DTS executa CREATE DATABASE IF NOT EXISTS \ test\`` no banco de dados de origem para avançar a posição do arquivo de log binário.

Etapa 1: Abrir a página de Migração de Dados

Utilize um dos métodos abaixo para acessar a página de Migração de Dados.

Etapa 2: Configurar a tarefa

Clique em Create Task para abrir a página de configuração da tarefa. Configure os parâmetros descritos na tabela a seguir.

Etapa 3: Testar conectividade

Clique em Test Connectivity and Proceed na parte inferior da página.

Adicione os blocos CIDR dos servidores DTS às configurações de segurança dos bancos de dados de origem e de destino. Consulte Adicionar os blocos CIDR dos servidores DTS . Se a origem ou o destino for um banco de dados autogerenciado que não utiliza o método de acesso Alibaba Cloud Instance , clique em Test Connectivity na caixa de diálogo CIDR Blocks of DTS Servers .

Etapa 4: Selecionar objetos para migração

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

Etapa 5: Configurar definições avançadas

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

Etapa 6: Configurar campos da tabela ClickHouse

Clique em Next: Configure Database and Table Fields para definir o Type, Primary Key Column, Sort Key, Distribution Key e Partition Key para cada tabela de destino no ClickHouse.

• O DTS fornece uma configuração padrão. Para revisar ou modificar todas as tabelas, defina Definition Status como All.

• Primary Key Column e Sort Key suportam chaves compostas — selecione vários campos na lista suspensa.

• Partition Key deve ser uma ou mais colunas de Primary Key Column. Apenas os tipos BIGINT, INT, TIMESTAMP, DATETIME e DATE são suportados. Campos anuláveis não podem ser usados como chave de partição. É permitido deixar a chave de partição em branco.

• Distribution Key aceita apenas um único campo.

Para detalhes sobre chaves primárias, chaves de ordenação e chaves de partição no ClickHouse, consulte CREATE TABLE.

Etapa 7: Executar pré-verificação

Clique em Next: Save Task Settings and Precheck.

Para visualizar os parâmetros de API correspondentes a esta configuração de tarefa, 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. Se a pré-verificação falhar:

1. Clique em View Details ao lado do item com falha.

2. Corrija o problema com base nos resultados da verificação.

3. Clique em Precheck Again.

Se um item de alerta puder ser ignorado: clique em Confirm Alert Details > Ignore > OK > Precheck Again. Ignorar alertas pode causar inconsistência de dados.

Etapa 8: Adquirir a instância e iniciar a migração

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

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

   Seção	Parâmetro	Descrição
   New Instance Class	Resource Group	O grupo de recursos para a instância de migração. Padrão: default resource group. Consulte O que é Resource Management?
   	Instance Class	A classe da instância determina a velocidade da migração. Consulte Classes de instâncias de migração de dados.

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

4. Clique em Buy and Start > OK.

Consultar dados migrados corretamente

O DTS utiliza o mecanismo ReplicatedReplacingMergeTree e adiciona os campos _sign, _is_deleted e _version às tabelas de destino. Sem a palavra-chave FINAL, as consultas podem retornar linhas duplicadas ou excluídas. Sempre use FINAL e filtre por _sign:

SELECT * FROM <table_name> FINAL WHERE _sign > 0;

A condição WHERE _sign > 0 filtra linhas marcadas como excluídas.

Requisitos de tabela para criação manual

Se você pular a migração de esquema, crie as tabelas de destino antes de iniciar a tarefa. As tabelas devem atender a estes requisitos.

• Community Edition: Crie uma tabela local e uma tabela distribuída. O nome da tabela distribuída deve corresponder ao nome da tabela de origem. O nome da tabela local deve ser <distributed_table_name>_local.

• Enterprise Edition: Crie uma tabela com o mesmo nome da tabela de origem.

Campos gerenciados pelo DTS

O DTS adiciona automaticamente os seguintes campos às tabelas de destino durante a migração de esquema.

Lógica de cálculo da chave de partição