Migrate self-managed MySQL to PolarDB for MySQL - PolarDB: Central de Documentação do Alibaba Cloud

Pré-requisitos

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

O banco de dados MySQL auto-gerenciado está conectado à Alibaba Cloud e os blocos CIDR dos servidores DTS foram adicionados às configurações de segurança dele (regras de grupo de segurança, firewalls, listas de permissões). Para obter detalhes, consulte Preparação.
(Para migração incremental) O log binário está ativado no banco de dados MySQL de origem. Para obter detalhes, consulte Crie uma conta para um banco de dados MySQL auto-gerenciado e configure o log binário.
Existe um cluster PolarDB for MySQL de destino com espaço de armazenamento maior que o do banco de dados de origem. Consulte Adquirir um cluster de pagamento conforme o uso ou Adquirir um cluster por assinatura.

Para versões de banco de dados compatíveis, consulte Visão geral dos cenários de migração de dados .

Tipos de migração

O DTS oferece suporte a três tipos de migração, que podem ser combinados:

Tipo de migração	Descrição
Schema migration	Migra os esquemas dos objetos selecionados (tabelas, visualizações, gatilhos, procedimentos armazenados, funções armazenadas) da origem para o destino.
Full data migration	Transfere todos os dados existentes do banco de dados de origem.
Incremental data migration	Após a conclusão da migração completa, espelha continuamente as alterações da origem para o destino, mantendo o serviço em execução durante a migração.

Comportamento da migração de esquema:

O DTS altera o atributo SECURITY de DEFINER para INVOKER em visualizações, procedimentos armazenados e funções, definindo o DEFINER como a conta do banco de dados de destino usada na migração.
O DTS não migra informações de usuário. Conceda permissões de leitura e gravação ao INVOKER no banco de dados de destino para chamar visualizações, procedimentos armazenados ou funções armazenadas.
O DTS migra chaves estrangeiras da origem para o destino. Durante a migração completa e incremental de dados, o DTS desativa temporariamente a verificação de restrições e operações em cascata nas chaves estrangeiras no nível da sessão.

Operações SQL com suporte na migração incremental de dados:

Tipo de operação	Instruções com suporte
DML	INSERT, UPDATE, DELETE
DDL	ALTER TABLE, ALTER VIEW, CREATE FUNCTION, CREATE INDEX, CREATE PROCEDURE, CREATE TABLE, CREATE VIEW, DROP INDEX, DROP TABLE, RENAME TABLE, TRUNCATE TABLE

Importante

Operações RENAME TABLE podem causar inconsistência de dados. Se você selecione uma tabela como objeto de migração e renomeá-la durante o processo, os dados poderão não chegar ao destino. Para evitar isso, selecione todo o banco de dados como objeto de migração e garanta que os bancos de dados contendo a tabela antes e depois da renomeação estejam incluídos.

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	Gratuita	Cobrada apenas quando o Access Method está definido como Public IP Address. Consulte Visão geral do faturamento.
Migração incremental de dados	Cobrada. Consulte Visão geral do faturamento.	—

Permissões necessárias

Conceda as seguintes permissões às contas de banco de dados usadas pelo DTS:

Banco de dados	Migração de esquema	Migração completa	Migração incremental
MySQL auto-gerenciado	SELECT	SELECT	SELECT nos objetos a serem migrados; REPLICATION CLIENT; REPLICATION SLAVE; SHOW VIEW; permissões para criar bancos de dados e tabelas (para que o DTS possa criar o banco de dados `test` e avançar a posição do log binário)
Cluster PolarDB for MySQL	Leitura e gravação	Leitura e gravação	Leitura e gravação

Para instruções, consulte:

MySQL auto-gerenciado: Crie uma conta para um banco de dados MySQL auto-gerenciado e configure o log binário
PolarDB for MySQL: Crie e gerencie contas de banco de dados

Limitações

Banco de dados de origem

O servidor deve ter largura de banda de saída suficiente; caso contrário, a velocidade de migração diminuirá.
As tabelas devem ter restrições PRIMARY KEY ou UNIQUE com todos os campos únicos; caso contrário, registros duplicados poderão aparecer no destino.
Ao renomear tabelas ou colunas no destino, uma única tarefa aceita até 1.000 tabelas. Para mais de 1.000 tabelas, configure várias tarefas ou migre todo o banco de dados.
Durante a migração de esquema e a migração completa de dados, não execute instruções DDL que alterem esquemas de banco de dados ou tabelas; a tarefa falhará.
Na migração apenas completa (sem incremental), não grave no banco de dados de origem; isso causa inconsistência de dados. Para manter a consistência, selecione migração de esquema, migração completa de dados e migração incremental de dados juntas.
Dados gerados por operações em cascata ou restaurados de um backup físico não são registrados nos logs binários e não serão migrados.
Se a origem for MySQL 8.0.23 ou posterior e os dados incluírem colunas invisíveis, essas colunas não poderão ser lidas e ocorrerá 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 geram automaticamente chaves primárias invisíveis. Torne essas chaves primárias invisíveis visíveis antes da migração. Consulte Generated Invisible Primary Keys .

Requisitos de log binário para migração incremental:

Parâmetro	Valor obrigatório	Observações
`binlog_format`	`ROW`	Se não estiver definido como `ROW`, a pré-verificação falhará e a tarefa não poderá ser iniciada.
`binlog_row_image`	`FULL`	Se não estiver definido como `FULL`, a pré-verificação falhará e a tarefa não poderá ser iniciada.
`log_slave_updates`	`ON`	Necessário apenas quando a origem é um MySQL auto-gerenciado em um cluster de primário duplo, para que o DTS possa ler todos os logs binários.
Retenção de log binário	Pelo menos 7 dias (MySQL auto-gerenciado)	Os logs binários de uma instância ApsaraDB RDS for MySQL devem ser retidos por pelo menos 3 dias; recomenda-se 7 dias. Se os logs binários forem removidos muito cedo, a tarefa poderá falhar ou ocorrer inconsistência de dados.

Origem MySQL auto-gerenciado: casos especiais

Se ocorrer um failover primário/secundário na origem enquanto a tarefa estiver em execução, a tarefa falhará.
A latência de migração é calculada com base no carimbo de data/hora dos dados migrados mais recentes no destino em relação à hora atual na origem. Se nenhuma operação DML for executada na origem por um longo período, a latência relatada poderá ser imprecisa. Execute uma operação DML na origem para atualizar o valor de latência. Se você migrar um banco de dados inteiro, crie uma tabela de heartbeat que seja atualizada a cada segundo.
Periodicamente, o DTS executa CREATE DATABASE IF NOT EXISTS na origem para avançar a posição do log binário.

Origem ApsaraDB RDS for MySQL: casos especiais

Na migração incremental de dados, uma instância ApsaraDB RDS for MySQL que não registra logs de transações, como 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 na origem para avançar a posição do log binário.

Banco de dados de destino (PolarDB for MySQL)

O DTS cria bancos de dados automaticamente no cluster de destino. Se o nome do banco de dados de origem não estiver em conformidade com as convenções de nomenclatura do PolarDB for MySQL, crie manualmente o banco de dados antes de configurar a tarefa. Consulte Gerencie bancos de dados.
Não há limitação de taxa disponível para migração completa de dados para o PolarDB for MySQL.

Outras limitações

As versões do MySQL de origem e de destino devem corresponder.
O DTS não migra dados que usam definições de parser especificadas por meio de comentários.
Agende a migração fora dos horários de pico. A migração completa de dados utiliza recursos de leitura e gravação de ambos os bancos de dados e aumenta a carga do servidor.
Após a migração completa de dados, operações INSERT simultâneas criam fragmentação de tabela no destino, tornando seu tablespace maior que o da origem.
Se os dados contiverem caracteres de quatro bytes (caracteres raros, emojis), o banco de dados e as tabelas de destino deverão usar o conjunto de caracteres UTF8mb4. Se você usar a migração de esquema do DTS, defina character_set_server como UTF8mb4 no banco de dados de destino.
O DTS usa ROUND(COLUMN, PRECISION) para ler colunas FLOAT e DOUBLE. Precisão padrão: 38 dígitos para FLOAT, 308 dígitos para DOUBLE. Verifique se as configurações de precisão atendem aos seus requisitos.
O DTS tenta novamente tarefas com falha por até 7 dias. Antes de alternar cargas de trabalho para o destino, pare ou libere qualquer tarefa com falha, ou revogue as permissões de gravação das contas do DTS. Caso contrário, o banco de dados de origem poderá sobrescrever os dados de destino quando uma tarefa com falha for retomada.
Valores DATETIME não podem ser convertidos para VARCHAR.
Se instruções DDL falharem no destino, a tarefa do DTS continuará em execução. Visualize as instruções DDL com falha nos logs da tarefa.
Se a origem for uma instância ApsaraDB RDS for MySQL com EncDB ativado, a migração completa de dados não terá suporte. A Criptografia Transparente de Dados (TDE) tem suporte para todos os três tipos de migração.
Para migrar contas, consulte Migrar contas de banco de dados.
Se uma tarefa do DTS falhar, o suporte técnico do DTS tentará restaurá-la dentro de 8 horas. A tarefa poderá ser reiniciada e certos parâmetros da tarefa poderão ser modificados durante a restauração. Os parâmetros do banco de dados não são modificados.

Configure e execute uma tarefa de migração

Etapa 1: Abrir a página Data Migration

Use qualquer um dos consoles para iniciar:

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 DMS

Nota

A operação real pode variar com base no modo e no layout do console do DMS. Para obter mais informações, consulte Modo simples e Personalizar o layout e o estilo do console do DMS.

Faça login no console do DMS
Na barra de navegação superior, acesse Data + AI > DTS (DTS) > Data Migration.
Na lista suspensa à direita de Data Migration Tasks, selecione a região.

Etapa 2: Configure os bancos de dados de origem e de destino

Clique em Create Task para abrir a página de configuração da tarefa.

Aviso

Após configurar os bancos de dados de origem e de destino, leia as Limits exibidas na parte superior da página antes de prosseguir; caso contrário, a tarefa poderá falhar ou ocorrer inconsistência de dados.

Task Name

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

Source Database

Parâmetro	Descrição
Select Existing Connection	Selecione uma instância registrada para preencher automaticamente os parâmetros ou configure a conexão manualmente.
Database Type	Selecione MySQL.
Access Method	Selecione o tipo de conexão com base na localização do banco de dados de origem. Este guia usa Public IP. Para outros tipos de instância, consulte Visão geral da preparação.
Instance Region	A região onde o banco de dados MySQL auto-gerenciado reside.
Hostname or IP address	O endereço IP público ou nome do host do banco de dados de origem.
Port	A porta de serviço do banco de dados de origem, que deve estar aberta para a internet. Padrão: 3306.
Database Account	A conta para o banco de dados de origem. Consulte Permissões necessárias.
Database Password	A senha da conta.
Encryption	Non-encrypted (se o SSL não estiver ativado) ou SSL-encrypted (se o SSL estiver ativado; carregue um Certificado CA e configure a Chave CA).

Destination Database

Parâmetro	Descrição
Select Existing Connection	Selecione uma instância registrada para preencher automaticamente os parâmetros ou configure a conexão manualmente.
Database Type	Selecione PolarDB for MySQL.
Access Method	Selecione Cloud Instance.
Instance Region	A região onde o cluster PolarDB for MySQL de destino reside.
PolarDB Instance ID	O ID do cluster PolarDB for MySQL de destino.
Database Account	A conta para o cluster de destino. Consulte Permissões necessárias.
Database Password	A senha da conta.
Encryption	Configure de acordo com seus requisitos. Consulte Configurar criptografia SSL.

Etapa 3: Testar a conectividade

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

Certifique-se de que os blocos CIDR dos servidores DTS possam ser adicionados (automaticamente ou manualmente) às configurações de segurança de ambos os bancos de dados. Consulte Adicionar os blocos CIDR dos servidores DTS .

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

Na página Configure Objects, configure o seguinte:

Parâmetro	Descrição
Migration Types	Selecione Schema Migration e Full Data Migration para uma migração única. Para manter a continuidade do serviço, selecione também Incremental Data Migration. Se você omitir a Schema Migration, crie manualmente o banco de dados e as tabelas de destino e ative o mapeamento de nomes de objetos em Selected Objects.
Method to migrate triggers in source database	Escolha um método de migração de gatilhos com base em seus requisitos. Disponível apenas quando os Migration Types incluem Schema Migration. Consulte Configurar o método para sincronizar ou migrar gatilhos.
Processing mode of conflicting tables	Precheck and Report Errors: falha na pré-verificação se existirem nomes de tabela idênticos na origem e no destino (use o mapeamento de nomes de objetos para renomear tabelas conflitantes). Ignore Errors and Proceed: ignora a pré-verificação para nomes de tabela idênticos. Observe que pode resultar em inconsistência de dados: durante a migração completa, o DTS não migra o registro conflitante e o registro existente no destino é mantido; durante a migração incremental, o DTS migra o registro e o registro existente no destino é sobrescrito.
Whether to migrate event	Selecione Yesconfigurações de notificação de alerta para migrar eventos e conclua as etapas subsequentes. Consulte Sincronizar ou migrar eventos.
Capitalization of object names in destination instance	Controla a caixa (maiúsculas/minúsculas) dos nomes de bancos de dados, tabelas e colunas no destino. Padrão: DTS default policy. Consulte Especificar a capitalização de nomes de objetos.
Source Objects	Selecione objetos e clique em para movê-los para Selected Objects. É possível selecionar colunas, tabelas ou esquemas. A seleção de tabelas ou colunas exclui visualizações, gatilhos e procedimentos armazenados.
Selected Objects	Clique com o botão direito em um objeto para renomeá-lo individualmente ou clique em Batch Edit para renomeação em massa. Para filtrar linhas, clique com o botão direito em uma tabela e defina uma condição WHERE. Para restringir operações SQL no nível do banco de dados ou da tabela, clique com o botão direito e selecione as operações a serem incluídas.

Etapa 5: Configure definições avançadas

Clique em Next: Advanced Settings e configure:

Parâmetro	Descrição
Dedicated cluster for task scheduling	Por padrão, o DTS usa o cluster compartilhado. Para maior estabilidade, adquira um cluster dedicado. Consulte O que é um cluster dedicado do DTS.
Select the engine type of the destination database	InnoDB (padrão) ou X-Engine (mecanismo de armazenamento para Processamento de Transações Online - OLTP).
Copy the temporary table of the online DDL tool	Controla o tratamento de tabelas temporárias criadas por ferramentas DDL online. Yes: migra dados da tabela temporária (pode aumentar a latência). No, Adapt to DMS Online DDL: migra apenas o DDL original do DMS (tabelas de destino podem ser bloqueadas). No, Adapt to gh-ost: migra apenas o DDL original do gh-ost (tabelas de destino podem ser bloqueadas). Não use pt-online-schema-change; isso causa falha na tarefa.
Whether to migrate accounts	Selecione Yes para migrar contas; em seguida, selecione as contas e confirme as permissões. Consulte Migrar contas de banco de dados.
Retry time for failed connections	Duração durante a qual o DTS tenta reconectar após uma falha de conexão. Intervalo: 10–1.440 minutos. Padrão: 720 minutos. Recomendamos definir o parâmetro com um valor superior a 30 minutos.
Retry time for other issues	Duração durante a qual o DTS tenta novamente após falhas de DDL ou DML. Intervalo: 1–1.440 minutos. Padrão: 10 minutos. Recomendamos definir o parâmetro com um valor superior a 10 minutos. Deve ser menor que o Retry time for failed connections.
Enable throttling for full data migration	Limita QPS, RPS e a velocidade de migração para reduzir a carga no destino. Configure QPS to the source database, RPS of Full Data Migration e Data migration speed for full migration (MB/s). Disponível apenas quando a Full Data Migration estiver selecionada.
Enable throttling for incremental data migration	Limita RPS e a velocidade de migração para migração incremental. Configure RPS of Incremental Data Migration e Data migration speed for incremental migration (MB/s). Disponível apenas quando a Incremental Data Migration estiver selecionada.
Whether to delete SQL operations on heartbeat tables	Yes: o DTS não grava operações da tabela de heartbeat na origem (a latência de migração pode ser exibida). No: o DTS grava operações da tabela de heartbeat na origem (pode afetar o backup físico e a clonagem do banco de dados de origem).
Configure ETL	Yes: ativa extração, transformação e carregamento (ETL); insira instruções de processamento no editor de código. No: ETL desativado. Consulte O que é ETL?
Monitoring and alerting	Yes: configura alertas para falhas de tarefa ou latência excedendo um limiar. Consulte Configurar monitoramento e alertas.

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

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

Etapa 7: Execute a pré-verificação e adquirir uma instância

Clique em Next: Save Task Settings and Precheck.

Para visualizar os parâmetros da API para esta configuração de tarefa, passe o mouse sobre Next: Save Task Settings and Precheck e clique em Preview OpenAPI parameters .
Aguarde a conclusão da pré-verificação.
- Se um item falhar, clique em View Details, corrija o problema e clique em Precheck Again.
- Se um alerta for acionado para um item que pode ser ignorado, clique em Confirm Alert Details > Ignore > OK, e então clique em Precheck Again.
Quando a Success Rate atingir 100%, clique em Next: Purchase Instance.

Na página Purchase Instance, defina a Instance Class:

Parâmetro	Descrição
Resource Group	O grupo de recursos para a instância de migração. Padrão: default resource group.
Instance Class	A classe da instância determina a velocidade de migração. Selecione com base em seus requisitos. Consulte Classes de instâncias de migração de dados.

Marque a caixa de seleção Data Transmission Service (Pay-as-you-go) Service Terms, depois clique em Buy and Start > OK.

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

Migração de esquema ou migração apenas completa: a tarefa para automaticamente. O status mostra Completed.
Incremental data migration: a tarefa é executada continuamente e não para automaticamente. O status mostra Running.

PolarDB:Migrar um banco de dados MySQL auto-gerenciado para o PolarDB for MySQL