ApsaraDB RDS:Migrar dados entre instâncias do ApsaraDB RDS for MySQL

Limitação

Solução alternativa

O servidor que hospeda o banco de dados de origem deve ter largura de banda de saída suficiente. A largura de banda insuficiente reduz a velocidade da migração.

Agende a migração para horários de menor movimento e ative o limitador nas configurações avançadas.

As tabelas a serem migradas devem ter restrições PRIMARY KEY ou UNIQUE com todos os campos exclusivos. Sem essas restrições, o destino pode conter registros duplicados.

Adicione uma chave primária ou uma restrição de unicidade à tabela antes da migração.

Se você selecionar tabelas como objetos de migração e precisar renomear tabelas ou colunas no destino, uma única tarefa oferece suporte a até 1.000 tabelas.

Para mais de 1.000 tabelas, configure várias tarefas ou migre o banco de dados inteiro.

Para migração de dados incrementais: o registro binário (binary logging) deve estar ativado, binlog_format deve estar definido como row e binlog_row_image deve estar definido como full. Se essas condições não forem atendidas, a pré-verificação falhará.

Ative o registro binário e defina os parâmetros necessários antes de iniciar a tarefa. Para um banco de dados MySQL autogerenciado em um cluster com dois primários, defina também log_slave_updates como ON.

Para migração de dados incrementais: os logs binários devem ser retidos por pelo menos 7 dias. Um período de retenção menor pode fazer com que o DTS falhe ao obter logs, resultando em inconsistência ou perda de dados, e o SLA do DTS pode não ser garantido.

Estenda o período de retenção do log binário para pelo menos 7 dias antes de iniciar a migração.

Durante a migração de esquema e a migração de dados completa, não execute instruções DDL para alterar esquemas de banco de dados ou tabelas. Isso causa a falha da tarefa.

Planeje e conclua todas as alterações de esquema antes de iniciar a tarefa de migração.

Se estiver executando apenas a migração de dados completa (sem a incremental), não grave dados na origem durante a migração.

Selecione a migração de esquema, a migração de dados completa e a migração de dados incrementais juntas para manter a consistência dos dados.

Dados alterados a partir de operações de log binário — como dados restaurados de um backup físico ou operações em cascata — não são registrados e não serão migrados enquanto a instância estiver em execução.

Execute uma migração de dados completa novamente após a conclusão da execução da instância, se o seu negócio permitir.

Para MySQL 8.0.23 ou posterior: colunas invisíveis causam perda de dados porque o DTS não consegue obter esses dados.

Execute ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; para tornar as colunas visíveis antes da migração. Consulte Invisible Columns. Tabelas sem chaves primárias geram automaticamente chaves primárias invisíveis; torne-as visíveis também. Consulte Generated Invisible Primary Keys.

Limitação

Solução alternativa

As versões dos bancos de dados MySQL de origem e de destino devem ser iguais.

Verifique a compatibilidade de versões antes de iniciar a migração.

O DTS não migra dados quando é utilizado um analisador (parser) definido por meio de comentários.

Remova os analisadores baseados em comentários antes da migração.

Para bancos de dados de destino MySQL 8.0.23 ou posterior: colunas invisíveis no destino causam falha na tarefa e perda de dados.

Execute ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; no destino antes de iniciar a tarefa.

Se você não usar a migração de esquema do DTS, garanta a compatibilidade dos tipos de campo manualmente. Por exemplo, se um campo de origem for text e o campo de destino for varchar(255), os dados podem ser truncados.

Use a migração de esquema do DTS ou verifique e alinhe manualmente os tipos de campo no destino antes da migração.

Se os dados de migração incluírem caracteres de 4 bytes (caracteres raros ou emojis), o banco de dados e as tabelas de destino devem usar o conjunto de caracteres UTF8mb4.

Se estiver usando a migração de esquema do DTS, defina character_set_server no destino como UTF8mb4. Se não estiver usando a migração de esquema, defina o conjunto de caracteres manualmente antes da migração.

A migração de dados completa consome recursos de leitura e gravação na origem e no destino, o que pode aumentar a carga do servidor.

Agende a migração para horários de menor movimento e ative o limitador nas configurações avançadas.

Durante a migração de dados completa, operações INSERT simultâneas causam fragmentação de tabela no destino. Após a migração, o tablespace de destino será maior que o de origem.

Execute OPTIMIZE TABLE no destino após a migração se o tamanho do tablespace for uma preocupação.

Para colunas FLOAT ou DOUBLE: o DTS usa ROUND(COLUMN,PRECISION). Se nenhuma precisão for especificada, o DTS usa como padrão 38 dígitos para FLOAT e 308 dígitos para DOUBLE.

Verifique se os valores de precisão padrão atendem aos seus requisitos antes de iniciar a tarefa.

O DTS tenta retomar tarefas com falha por até 7 dias. Se não for interrompida antes de você alternar as cargas de trabalho, uma tarefa retomada pode sobrescrever os dados de destino com os dados de origem.

Interrompa ou libere quaisquer tarefas com falha antes de alternar as cargas de trabalho para o destino. Como alternativa, execute REVOKE para revogar as permissões de gravação das contas do DTS no destino.

Se as instruções DDL falharem ao serem executadas no destino, a tarefa do DTS continuará.

Visualize as instruções DDL com falha nos logs da tarefa. Consulte Visualize logs da tarefa.

Se os nomes das colunas na mesma tabela MySQL de destino diferirem apenas na capitalização, os resultados podem ser inesperados, pois os nomes das colunas do MySQL não diferenciam maiúsculas de minúsculas.

Normalize a capitalização dos nomes das colunas no destino antes da migração.

Após a conclusão da migração (o Status da instância muda para Completed), os dados gravados durante um failover de alta disponibilidade (HA) podem existir apenas na memória, causando perda de dados.

Execute analyze table <table name> no destino após a migração e verifique se os dados foram gravados com sucesso.

Instâncias RDS MySQL com EncDB ativado não oferecem suporte à migração de dados completa.

Desative o EncDB ou use uma abordagem de migração diferente. Observação: instâncias RDS MySQL com TDE ativado oferecem suporte à migração de esquema, migração de dados completa e migração de dados incrementais.

Se uma tarefa do DTS falhar, o suporte técnico do DTS tentará restaurá-la em até 8 horas. Durante a restauração, a tarefa pode ser reiniciada e os parâmetros da tarefa (não os parâmetros do banco de dados) podem ser modificados.

Nenhuma ação é necessária; isso é tratado pelo suporte do DTS.

Cenário

Limitação

Solução alternativa

Origem MySQL autogerenciada

Um failover primário/secundário enquanto a tarefa está em execução causa a falha da tarefa.

Evite failovers durante a migração.

Origem MySQL autogerenciada

O DTS executa CREATE DATABASE IF NOT EXISTS \ test\`` na origem de forma agendada para avançar a posição do log binário. Se nenhuma operação DML for executada na origem por um longo período, as leituras de latência da migração podem ser imprecisas.

Execute uma operação DML na origem e atualize o valor de latência. Se estiver migrando um banco de dados inteiro, crie uma tabela de heartbeat que receba dados a cada segundo.

Origem ApsaraDB RDS for MySQL

Uma instância ApsaraDB RDS for MySQL V5.6 somente leitura que não registra logs de transações não pode ser usada como origem para migração de dados incrementais.

Use uma instância de origem ou tipo de migração diferente.

Origem ApsaraDB RDS for MySQL

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

Nenhuma ação é necessária; isso é tratado automaticamente pelo DTS.

Destino ApsaraDB RDS for MySQL

O DTS cria automaticamente o banco de dados de destino. No entanto, 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, a criação automática falhará.

Crie manualmente o banco de dados na instância de destino antes de configurar a tarefa de migração. Consulte Gerencie bancos de dados.