Quais são as melhores práticas a serem seguidas ao migrar um banco de dados MySQL do RDS de origem para um banco de dados MySQL do RDS de destino usando o AWS DMS?

Descrição breve

Com o AWS DMS, é possível migrar dados de um armazenamento de dados de origem para um armazenamento de dados de destino. Esses dois armazenamentos de dados são chamados de endpoints. A migração pode ser feita entre endpoints de origem e destino que usam o mesmo mecanismo de banco de dados, como de um banco de dados MySQL para outro banco de dados MySQL.

Embora o AWS DMS crie os objetos do esquema de destino, ele cria apenas os objetos mínimos necessários para que os dados sejam efetivamente migrados da origem. Portanto, o AWS DMS cria tabelas, chaves primárias e, em alguns casos, índices exclusivos, mas não cria objetos como índices secundários, restrições de chaves não primárias e padrões de dados. Para obter mais informações sobre as entidades migradas pelo AWS DMS, consulte Visão de alto nível do AWS DMS.

Pré-criar as tabelas no banco de dados de destino antes da migração

Para preservar as definições de dados padrão, crie previamente as tabelas no banco de dados de destino antes da migração. Use uma dessas abordagens, dependendo do tipo de migração que está sendo realizado:

• Para migrações homogêneas, como MySQL para MySQL, use os utilitários nativos do mecanismo de banco de dados, como mysqldump, para fazer uma exportação das definições das tabelas. Em seguida, importe essas definições de tabelas para o destino, mas sem os dados. Depois que as definições de tabelas forem criadas, use a tarefa do AWS DMS com o modo de preparação da tabela de destino definido como TRUNCATE_BEFORE_LOAD para carregar os dados.
• Para migrações entre diferentes mecanismos de banco de dados, use a AWS Schema Conversion Tool (AWS SCT). Esse método também pode ser usado para bancos de dados homogêneos. A AWS SCT conecta aos bancos de dados de origem e de destino e, em seguida, converte o esquema de banco de dados existente de um mecanismo de banco de dados para o outro. A AWS SCT pode ser usada para pré-criar tabelas no banco de dados de destino com as definições de dados padrão intactas. Em seguida, use a tarefa do AWS DMS com o modo de preparação de tabelas de destino definido como TRUNCATE_BEFORE_LOAD para carregar os dados. Para obter mais informações, consulte Converter esquemas de banco de dados usando a AWS SCT.

Resolução

Siga as práticas recomendadas para migração do AWS DMS de MySQL para MySQL

Use essas práticas recomendadas ao migrar dados de um banco de dados de origem MySQL para um banco de dados de destino MySQL.

• Desative backups e logs específicos do banco de dados (como bin, geral e auditoria) no banco de dados de destino durante a migração. Se necessário, você poderá ativá-los novamente para solucionar problemas.
• Desative gatilhos, outros trabalhos do cron e programadores de eventos no banco de dados de destino durante a migração.
• Evite usar Multi-AZ no banco de dados do Amazon RDS de destino ao realizar a migração do AWS DMS.
• Evite aplicar qualquer outro tráfego de cliente externo ao banco de dados de destino ao realizar a migração.
• Provisione sua instância de replicação do AWS DMS e os bancos de dados de origem e de destino com a CPU, a memória, o armazenamento e as IOPS necessários para evitar a contenção de recursos durante a migração.
• Configure o banco de dados de origem com os pré-requisitos para usar a captura de dados de alteração (CDC) do AWS DMS antes de iniciar a migração.
• Use configurações de LOB otimizadas, como LOB limitado e LOB em linha, para migração.
• Se o banco de dados de origem contiver muitas tabelas com uma workload pesada, divida as tabelas entre várias tarefas. Divida as tabelas com base em seu tamanho no banco de dados de origem, no padrão de tráfego da aplicação e na presença de colunas LOB. Se a tabela tiver muitas colunas LOB (TEXT ou JSON) com tráfego de gravação elevado na origem, crie uma tarefa separada para a tabela. A consistência transacional é mantida dentro de uma tarefa e, por isso, é importante que tabelas em tarefas separadas não participem de transações comuns.
• Use o mecanismo paralelo de carga total para tabelas de origem pesadas para reduzir o tempo de migração. Para obter mais informações, consulte Usar carga paralela para tabelas, exibições e coleções selecionadas.
• Desative as restrições de chave estrangeira na tabela de destino durante a migração de carga total.
• Adicione um índice secundário ao banco de dados de destino antes de iniciar a fase de replicação do CDC.
• O usuário principal do Amazon RDS não tem privilégios para descartar e recriar nas tabelas de esquema padrão. Portanto, evite migrar tabelas de esquema ou banco de dados padrão da origem usando o AWS DMS.
• Consulte a documentação sobre como Usar o AWS DMS para migrar dados do MySQL para o MySQL para obter informações sobre quais tipos de dados o AWS DMS pode migrar com êxito.
• Teste sua workload usando o apply transacional padrão de CDC antes de usar o método de CDC apply em lote. Para obter mais informações, Como posso usar o recurso de aplicação em lote do DMS para melhorar a performance de replicação de CDC?
• Teste a migração usando os mesmos dados de produção em qualquer outro ambiente de banco de dados de QA/DEV antes de iniciar a migração no ambiente de produção. Certifique-se de usar a mesma configuração do AWS DMS ao fazer a migração de produção.

Para obter mais informações, consulte Melhorar a performance de uma migração do AWS DMS.

Use a configuração e os métodos recomendados em seus bancos de dados de origem e de destino

1. Crie previamente e de forma manual a tabela DDL nos bancos de dados MySQL/PostgreSQL de destino. Em seguida, crie uma tarefa do AWS DMS com o modo de preparação de destino definido como DO_DOTHING"/"TRUNCATE para migrar somente os dados.

Execute este comando para criar um despejo sem dados do banco de dados MySQL de origem:

mysqldump -h yourhostnameorIP -u root -p --no-data --skip-triggers --single-transaction --dbname > schema.sql

Esse comando despeja a estrutura DDL da origem sem nenhum dado.

Em seguida, execute este comando para restaurar a estrutura DDL no destino:

mysql -u user -p -h yourhostnameorIP  database_name < schema.sql

Outra opção é permitir que o AWS DMS crie as tabelas no destino usando o modo de preparação de destino DROP AND CREATE. Em seguida, pule para a etapa 3 para alterar a tabela e adicionar objetos que estão faltando, como índices secundários, antes de retomar a tarefa para a fase de CDC.

Observação: por padrão, o AWS DMS cria a tabela no destino apenas com a chave primária ou a chave exclusiva. Ele não migra nenhum outro objeto para o banco de dados MySQL de destino.

2. Durante a carga total, o AWS DMS não identifica as tabelas relacionais de chave estrangeira. Ele carrega os dados aleatoriamente. Assim, o carregamento da tabela poderá falhar se o banco de dados de destino tiver uma verificação de chave estrangeira ativada. Use esse atributo de conexão extra (ECA) no endpoint MySQL de destino para desativar verificações de chave estrangeira para esta sessão do AWS DMS.

initstmt=SET FOREIGN_KEY_CHECKS=0;

Para obter mais informações, consulte Atributos de conexão extras ao usar um banco de dados compatível com MySQL como destino para o AWS DMS.

3. Nas configurações JSON, defina stop task antes de aplicar as alterações no cache como true e stop task depois de aplicar as alterações no cache como true.

"FullLoadSettings": {
    "TargetTablePrepMode": "TRUNCATE_BEFORE_LOAD"
    "CreatePkAfterFullLoad": false,
    "TransactionConsistencyTimeout": 600,
    "MaxFullLoadSubTasks": 8,
    "StopTaskCachedChangesNotApplied": true,   <--- set this to true
    "StopTaskCachedChangesApplied": true,    <--- set this to true
    "CommitRate": 50000,
}

Depois que a carga total for concluída e antes de aplicar as alterações armazenadas no cache, a tarefa será interrompida. Enquanto a tarefa estiver parada, crie índices de chave primária e índices secundários no destino.

Em seguida, retome a tarefa porque ela é interrompida novamente após aplicar as alterações armazenadas no cache. Em seguida, verifique os dados migrados usando a saída de validação do AWS DMS ou a verificação manual antes de retomar a tarefa novamente para a fase de replicação de CDC. Ao concluir esta etapa, você poderá identificar quaisquer problemas e resolvê-los antes de retomar a replicação de CDC.

4.    Nas configurações de carregamento total da tarefa, ajuste a configuração commitRate para acelerar a taxa de extração de dados da origem. O valor padrão é 10.000, portanto, ajuste essa configuração quando estiver migrando uma grande quantidade de dados da tabela de origem.

CommitRate=50000

Observação: alterar commitRate para um valor mais alto poderá afetar a performance. Por isso, certifique-se de monitorar e de que haja memória suficiente na instância de replicação.

5.    Adicione este ECA no endpoint de destino para especificar o tamanho máximo (em KB) de qualquer arquivo .csv usado para transferir dados para o MySQL de destino. O valor padrão é 32.768 KB (32 MB), e os valores válidos variam de 1 a 1.048.576 KB (até 1,1 GB).

maxFileSize=250000;

Observação: ao utilizar uma instância de destino como MySQL, Aurora ou MariaDB para carga total, use essa opção para permitir que o AWS DMS crie um arquivo .csv em segundo plano para carregar os dados na instância de destino. Use um valor entre 32 MB e 1 GB. Mas considere também com quanto a instância de destino pode lidar. Se houver várias tarefas carregando 1 GB de arquivo .csv, isso poderá sobrecarregar a instância de destino. Verifique se você tem uma instância com alto poder de computação no destino.

6.    Use as configurações de LOB limitado ou de LOB em linha para melhorar a performance.

Modo LOB limitado: ao usar o modo LOB limitado, você especifica o tamanho máximo dos dados da coluna LOB. Isso permite que o AWS DMS pré-aloque recursos e aplique LOB em massa. Se o tamanho das colunas LOB exceder o tamanho especificado na tarefa, o AWS DMS truncará os dados. Em seguida, o AWS DMS enviará avisos para o arquivo de log do AWS DMS. O uso do modo LOB limitado melhora a performance. No entanto, antes de executar a tarefa, é necessário identificar o tamanho máximo de LOB dos dados na origem. Em seguida, especifique o parâmetro de tamanho máximo de LOB. É prática recomendada garantir que haja memória suficiente alocada para a instância de replicação para lidar com a tarefa.

Modo LOB em linha: ao usar o modo LOB em linha, é possível migrar LOBs sem truncar dados ou diminuir a performance da tarefa por meio da replicação LOBs pequenos e grandes. Primeiro, especifique um valor para o parâmetro InlineLobMaxSize, que estará disponível somente quando o modo LOB completo estiver definido como true. A tarefa do AWS DMS transfere os LOBs em linha pequenos, o que é mais eficiente. Em seguida, o AWS DMS migra LOBs maiores do que o tamanho especificado no modo LOB completo executando uma pesquisa na tabela de origem. Observe, no entanto, que o modo LOB em linha funciona somente durante a fase de carga total.

Observação: é necessário definir InlineLobMaxSize ao especificar as configurações da tarefa para sua tarefa.

Execute essas consultas para verificar o tamanho do LOB e, em seguida, preencha o tamanho máximo de LOB.

Liste as tabelas que têm colunas LOB:

select tab.table_name,
count(*) as columns
from information_schema.tables as tab
inner join information_schema.columns as col
on col.table_schema = tab.table_schema
and col.table_name = tab.table_name
and col.data_type in ('blob', 'mediumblob', 'longblob',
'text', 'mediumtext', 'longtext')
where tab.table_schema = 'your database name'.  <---- enter database name here
and tab.table_type = 'BASE TABLE'
group by tab.table_name
order by tab.table_name;

Verifique o tamanho da coluna LOB:

Select (max(length (<COL_NAME>))/(1024)) as “size in KB” from <TABLE_NAME>;

Verifique o tamanho das colunas LOB para todas as tabelas e, em seguida, preencha o tamanho máximo em Max LOB size (K) (Tamanho máximo de LOB [K]).

O uso da opção de tamanho máximo de LOB (K) com um valor superior a 63 KB afeta o desempenho de uma carga total configurada para ser executada no modo LOB limitado. Durante uma carga total, o AWS DMS aloca memória multiplicando o valor do tamanho máximo de LOB (k) pela taxa de confirmação. Em seguida, o produto é multiplicado pelo número de colunas LOB.

Quando o AWS DMS não consegue pré-alocar essa memória, o AWS DMS começa a consumir memória de SWAP. Isso afeta a performance de uma carga total. Portanto, se você enfrentar problemas de performance ao usar o modo LOB em linha, diminua a taxa de confirmação até atingir um nível aceitável de performance. Outra possibilidade é considerar o uso do modo LOB em linha para endpoints compatíveis depois de verificar primeiro a distribuição de LOB para a tabela.

Para obter mais informações, consulte Configurar o suporte a LOB para bancos de dados de origem em uma tarefa do AWS DMS.

---

Informações relacionadas

Migrar do MySQL para o Amazon RDS com o AWS DMS

Instruções passo a passo da migração de banco de dados