Migração de Banco de Dados Relacional para Data Lake S3 Via AWS DMS, Parte I

O AWS Database Migration Service é um serviço em nuvem que migra bancos de dados relacionais, bancos de dados NoSQL, armazéns de dados e todos os outros tipos de armazenamentos de dados para a AWS Cloud ou entre configurações em nuvem e locais de forma eficiente e segura. O DMS suporta vários tipos de bancos de dados de origem e destino, como Oracle, MS SQL Server, MySQL, Postgres SQL, Amazon Aurora, AWS RDS, Redshift e S3, etc.

Observações Durante a Migração de Dados

Trabalhamos no design e criação de um data lake AWS S3 e armazém de dados no AWS Redshift com as fontes de dados locais para Oracle, MS SQL Server, MySQL, Postgres SQL e MongoDB para bancos de dados relacionais. Usamos o AWS DMS para a carga inicial completa e a transferência diária de dados incrementais dessas fontes para o AWS S3.

Com esta série de postagens, quero explicar os vários desafios enfrentados durante a migração real de dados com diferentes bancos de dados relacionais.

1. Data Modificada Não Preenchida Corretamente na Fonte

O AWS DMS é usado para carga completa e captura de dados de mudança a partir de bancos de dados de origem. O AWS DMS captura registros alterados com base nos logs de transação, mas uma coluna de data modificada atualizada corretamente pode ajudar a aplicar lógica de deduplicação e extrair o último registro modificado para uma determinada linha no destino em S3.

Caso os dados modificados não estejam disponíveis para uma tabela ou não sejam atualizados corretamente, o AWS DMS oferece uma opção de regras de transformação para adicionar uma nova coluna ao extrair dados do banco de dados de origem. Aqui, o AR_H_CHANGE_SEQ cabeçalho ajuda a adicionar uma nova coluna com um valor como um número único e crescente do banco de dados de origem, que consiste em um carimbo de data/hora e um número de incremento automático.

O exemplo de código abaixo adiciona uma nova coluna como DMS_CHANGE_SEQ ao destino, que possui um número único e crescente da origem. Este é um número único de 35 dígitos, com os primeiros 16 dígitos para o carimbo de data/hora e os próximos 19 dígitos para o número de ID do registro incrementado pelo banco de dados.

{

    "rule-type": "transformation",

    "rule-id": "2",

    "rule-name": "2",

    "rule-target": "column",

    "object-locator": {

        "schema-name": "%",

        "table-name": "%"

    },

    "rule-action": "add-column",

    "value": "DMS_CHANGE_SEQ",

    "expression": "$AR_H_CHANGE_SEQ",

    "data-type": {

        "type": "string",

        "length": 100

    }

}

2. Habilitando o Registro Suplementar para Oracle como Fonte

Para o Oracle como banco de dados de origem, para capturar alterações em andamento, AWS DMS precisa que o registro suplementar mínimo seja habilitado no banco de dados de origem. Assim, isso incluirá informações adicionais e colunas nos logs de redo para identificar as mudanças na origem.

O registro suplementar pode ser habilitado para chaves primárias, chaves únicas, conjuntos de colunas ou todas as colunas. O registro suplementar para todas as colunas captura todas as colunas das tabelas no banco de dados de origem e ajuda a sobrescrever os registros completos na camada AWS S3 de destino.

O registro suplementar de todas as colunas aumentará o tamanho dos logs de redo, uma vez que todas as colunas da tabela são registradas nos logs. É necessário configurar, redo e arquivar logs de acordo para considerar informações adicionais neles.

3. Largura de Banda da Rede Entre os Bancos de Dados Fonte e Destino

A carga inicial total das fontes locais para Oracle, MS SQL Server, etc., funcionou bem e a captura de dados alterados também, na maior parte do tempo.

Havia um número moderado de transações na maior parte do dia em um determinado mês, exceto pelo processo de fim de dia, diariamente, após a meia-noite, e atividades de fim de mês. Observamos que as tarefas de migração do DMS estavam fora de sincronização ou falharam durante esse tempo.

Revisamos as métricas da instância de origem, destino e replicação nos logs e encontramos as seguintes observações:

• CDCLatencySource – a lacuna, em segundos, entre o último evento capturado do ponto final de origem e o carimbo de data/hora atual da instância AWS DMS.
• CDCIncomingchanges – o número total de eventos de mudança em um determinado momento que está aguardando para ser aplicado ao destino. Isso aumenta de zero a milhares durante as atividades de reconciliação nas primeiras horas da manhã.
• CDCLatencySource – o intervalo, em segundos, entre o último evento capturado do ponto de extremidade de origem e o timestamp do sistema atual da instância AWS DMS. Isso aumenta de zero para alguns milhares, chegando a 10-12K segundos durante as atividades de reconciliação diárias após a meia-noite. Esse valor chegou a 40K durante as atividades de fim de mês.

Após uma análise mais detalhada dos logs e revisão de outras métricas, observamos que:

Métricas AWS DMS NetworkReceiveThroughput servem para entender o tráfego de entrada na instância de replicação DMS tanto para o banco de dados do cliente quanto para o tráfego DMS. Essas métricas ajudam a entender problemas relacionados à rede, se houver, entre o banco de dados de origem e a instância de replicação DMS.

Foi observado que o throughput de recebimento de rede chegou a 30MB/s, ou seja, 250Mb/s, devido à conexão VPN entre a origem e a AWS, que também era compartilhada por outros aplicativos.

A conclusão final sobre este problema é que a conectividade entre os bancos de dados de origem e destino é crítica para uma migração de dados bem-sucedida. Você deve garantir largura de banda suficiente entre bancos de dados de origem locais ou em outras nuvens e o ambiente AWS antes da migração real de dados.

1. Um túnel VPN, como o AWS Site-to-Site VPN ou Oracle Cloud Infrastructure (OCI) Site-to-Site VPN (Oracle AWS), pode fornecer um throughput de até 1,25 Gbps. Isso seria suficiente para a migração de tabelas pequenas ou tabelas com menos tráfego DML.
2. Para grandes migrações de dados com pesadas transações por segundo nas tabelas, você deve considerar o AWS Direct Connect. Ele oferece uma opção para criar uma conexão privada dedicada com suporte a largura de banda de 1 Gbps, 10 Gbps, etc.

Conclusão

Esta é a Parte I da série de várias partes sobre os desafios da migração de bancos de dados relacionais utilizando o AWS DMS e suas soluções implementadas. A maioria desses desafios mencionados nesta série pode ocorrer durante o processo de migração do banco de dados e essas soluções podem ser consultadas.