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

O AWS Database Migration Service é um serviço de nuvem que migra bancos de dados relacionais, bancos de dados NoSQL, data warehouses e todos os outros tipos de repositórios de dados de forma eficiente e segura para a AWS Cloud ou entre configurações em nuvem e locais. O DMS suporta vários tipos de bancos de dados de origem e de 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 projeto e criação de um data lake AWS S3 e um data warehouse no AWS Redshift com as fontes de dados locais para Oracle, MS SQL Server, MySQL, Postgres SQL e MongoDB para bancos de dados relacionais. Utilizamos o AWS DMS para a carga completa inicial e transferência diária incremental de dados dessas fontes para o AWS S3. 

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

1. Data de Modificação Não Preenchida Corretamente na Origem

O AWS DMS é usado para a carga completa e captura de dados alterados dos 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 registro modificado mais recente para uma linha específica no alvo no S3.

Caso os dados modificados não estejam disponíveis para uma tabela ou não sejam atualizados corretamente, a AWS DMS fornece uma opção de regras de transformação para adicionar uma nova coluna ao extrair dados do banco de dados de origem. Aqui, o cabeçalho AR_H_CHANGE_SEQ ajuda a adicionar uma nova coluna com um valor como um número de incremento único 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 no destino, que tem um número de incremento único do banco de dados de 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 Log Suplementar para Oracle como Origem

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

O log suplementar pode ser habilitado para chaves primárias, únicas, conjuntos de colunas ou todas as colunas. O log 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 de destino AWS S3.

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

3. Largura de banda de rede entre os bancos de dados de origem e de destino

A carga completa inicial das fontes locais para Oracle, MS SQL Server, etc., funcionou bem, assim como a captura de dados alterados na maior parte do tempo. 

Costumava haver um número moderado de transações na maior parte do dia em um determinado mês, exceto no processo de fim de expediente, diariamente, pós-meia-noite e atividades de fim de mês. Observamos que as tarefas de migração DMS estavam fora de sincronia ou falhavam durante esse período.

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

• CDCLatencySource – a diferença, em segundos, entre o último evento capturado no ponto de extremidade de origem e o carimbo de data/hora do sistema atual da instância do AWS DMS.
• CDCIncomingchanges – o número total de eventos de alteração em um determinado momento que estão aguardando aplicação no destino. Isso aumenta de zero para milhares durante as atividades de reconciliação de madrugada.
• CDCLatencySource – o intervalo, em segundos, entre o último evento capturado do ponto de extremidade de origem e o carimbo de data/hora do sistema atual da instância AWS DMS. Isso aumenta de zero para alguns milhares até 10-12 mil segundos durante as atividades diárias de reconciliação pós-meia-noite. Esse valor chegou a 40 mil durante as atividades de fim de mês.

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

As métricas da AWS DMS NetworkReceiveThroughput servem para entender o tráfego de entrada na instância de replicação DMS para ambos os bancos de dados do cliente e o tráfego DMS. Essas métricas ajudam a entender os 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 estava chegando a 30MB/s, ou seja, 250Mb/s, devido à conexão VPN entre a origem e a AWS, que também era compartilhada por outras aplicações.

A conclusão final para este problema é que a conectividade entre os bancos de dados de origem e destino é crucial para o sucesso da migração de dados. Você deve garantir largura de banda suficiente entre os bancos de dados de origem locais ou de outras nuvens e o ambiente da AWS está configurada antes da migração real de dados.

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

Conclusão

Esta é a Parte I da série de várias partes para os desafios de 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.