Simplifique migrações de grandes objetos binários: uma solução baseada em Kafka para Oracle para Amazon Aurora PostgreSQL e Amazon S3

Os clientes que migram de bancos de dados Oracle locais para a AWS enfrentam um desafio: realocar com eficiência grandes tipos de dados de objetos (LOBs) para armazenamento de objetos, mantendo a integridade e o desempenho dos dados. Esse desafio tem origem no design tradicional de banco de dados corporativo, onde os LOBs são armazenados junto com dados estruturados, levando a restrições de capacidade de armazenamento, complexidade de backup e gargalos de desempenho durante a recuperação e o processamento de dados. LOBs, que podem incluir imagens, vídeos e outros arquivos grandes, muitas vezes fazem com que as migrações de dados tradicionais sofram de velocidades lentas e problemas de truncamento de LOB. Estas questões são particularmente problemáticas para migrações de longa duração que podem durar vários anos.

Neste publish, apresentamos uma solução escalável que utiliza Amazon Managed Streaming para Apache Kafka (Amazon MSK), Edição compatível com Amazon Aurora PostgreSQLe Amazon MSK Conectar. O streaming de dados permite a replicação de dados onde as modificações são enviadas e recebidas em um fluxo contínuo, permitindo que o banco de dados de destino acesse e aplique as alterações em tempo actual. Esta solução gera eventos para ações de banco de dados como inserir, atualizar e excluir, acionando AWS Lambda funções para baixar LOBs do banco de dados Oracle de origem e carregá-los para Serviço de armazenamento simples da Amazon (Amazon S3) baldes. Simultaneamente, os eventos de streaming migram os dados estruturados do banco de dados Oracle para o banco de dados de destino, mantendo a vinculação adequada com seus respectivos LOBs.

A implementação completa está disponível em GitHubincluindo Package de desenvolvimento de nuvem AWS (AWS CDK), arquivos de configuração e instruções de configuração.

Visão geral da solução

Embora as migrações tradicionais de bancos de dados Oracle lidem com dados estruturados de maneira eficaz, elas enfrentam dificuldades com LOBs que podem incluir imagens, vídeos e documentos. Muitas vezes, essas migrações falham devido a limitações de tamanho e problemas de truncamento, criando riscos comerciais significativos, incluindo perda de dados, tempo de inatividade prolongado e atrasos em projetos que podem forçá-lo a adiar suas iniciativas de transformação na nuvem. O problema torna-se mais agudo durante migrações de longa duração, que abrangem vários anos, onde a manutenção da continuidade operacional é crítica. Esta solução aborda os principais desafios da migração LOB, permitindo operações contínuas e de longo prazo sem comprometer o desempenho ou a confiabilidade.

Ao remover as limitações de tamanho associadas às tecnologias de migração tradicionais, nossa solução fornece uma estrutura robusta que ajuda você a realocar LOBs de maneira transparente e, ao mesmo tempo, facilita a integridade dos dados durante todo o processo.

Nossa abordagem usa uma arquitetura de streaming moderna para aliviar as restrições tradicionais da migração Oracle LOB. A solução inclui os seguintes componentes principais:

• Amazon MSK – Fornece a infraestrutura de streaming.
• Amazon MSK Conectar – Usando dois conectores:
  • Conector Debezium para Oracle como um conector de origem para capturar alterações em nível de linha que ocorrem no banco de dados Oracle. O conector emite eventos de alteração e publica em um tópico de origem do Kafka.
  • Conector Debezium para JDBC como um conector de coletor para consumir eventos do tópico de origem do Kafka e, em seguida, gravar esses eventos no Aurora compatível com PostgreSQL usando um driver JDBC.
• Função Lambda – Acionado por um mapeamento de origem de eventos para o Amazon MSK. A função processa eventos do tópico de origem Kafka, extraindo a chave primária da linha Oracle de cada carga de evento. Ele usa essa chave para fazer obtain dos dados BLOB correspondentes do banco de dados Oracle de origem e carregá-los no Amazon S3, organizando os arquivos por pastas de chave primária para manter a vinculação simples com os registros do banco de dados relacional.
• Amazon RDS para Oracle – Amazon Relational Database Service (Amazon RDS) para Oracle é usado como banco de dados de origem para simular um banco de dados Oracle native.
• Compatível com Aurora PostgreSQL – Usado como banco de dados de destino para dados migrados.
• Amazon S3 – Usado como armazenamento de objetos para armazenar os dados BLOB do banco de dados de origem.

O diagrama a seguir mostra a solução de arquitetura de migração de dados Oracle LOB.

Fluxo de mensagens

Quando ocorrem alterações de dados no banco de dados de origem do Amazon RDS for Oracle, a solução executa a seguinte sequência, passando pela detecção e publicação de eventos, processamento BLOB com Lambda e processamento estruturado de dados:

1. O conector de origem Oracle captura os eventos de change knowledge seize (CDC), incluindo a mudança na coluna de dados BLOB. Este conector configura a coluna de dados BLOB para exclusão do evento Kafka para otimizar a carga útil do Kafka.
2. O conector publica esse evento em um tópico do MSK.
   1. O evento MSK aciona a função BLOB Downloader Lambda para os eventos do CDC.
      1. A função Lambda examina duas condições principais: o código de evento do Debezium (verificando especificamente create (c) ou replace(u)) e a lista configurada de nomes de tabelas Oracle BLOB junto com seus nomes de colunas. Quando uma mensagem Kafka corresponde à lista de tabelas configuradas e aos eventos Debezium válidos, a função Lambda inicia o obtain de dados BLOB da origem Oracle usando a chave primária e o nome da tabela; caso contrário, a função ignora o processo de obtain do BLOB. Essa abordagem seletiva garante que a função Lambda execute apenas consultas SQL ao processar mensagens Kafka para tabelas contendo dados BLOB, otimizando as interações com o banco de dados.
      2. A função Lambda carrega o BLOB no Amazon S3, organizando por pastas de chave primária com nomes de objetos exclusivos, o que permite a vinculação entre registros de banco de dados estruturados e seus dados BLOB correspondentes no Amazon S3.
   2. O conector do coletor PostgreSQL recebe o evento do tópico MSK.
      1. O conector aplica essas alterações ao banco de dados Aurora PostgreSQL para as alterações do banco de dados Oracle, exceto a coluna de dados BLOB. A coluna de dados BLOB é excluída pelo conector de origem Oracle.

Principais benefícios

A solução oferece as seguintes vantagens principais:

• Otimização de custos e licenciamento – Nossa abordagem oferece benefícios significativos de otimização de custos, reduzindo o tamanho geral do seu banco de dados e aliviando a necessidade de licenças caras associadas a bancos de dados tradicionais e tecnologias de replicação. Ao desacoplar o armazenamento LOB do banco de dados e usar o Amazon S3, você pode reduzir o espaço whole do banco de dados e reduzir os custos associados às tecnologias tradicionais de licenciamento e replicação. A arquitetura de streaming também minimiza a sobrecarga da infraestrutura durante migrações de longa duração.
• Evita restrições de tamanho e falhas de migração – As ferramentas de migração tradicionais muitas vezes impõem limitações de tamanho nas transferências LOB, levando a problemas de truncamento e falhas nas migrações. Essa solução take away totalmente essas restrições, para que você possa migrar LOBs de tamanhos diferentes e, ao mesmo tempo, manter a integridade dos dados. A arquitetura orientada a eventos permite a replicação de dados quase em tempo actual, permitindo que seus sistemas de origem permaneçam operacionais durante a migração.
• Continuidade dos negócios e excelência operacional – As alterações fluem continuamente para o seu ambiente de destino, permitindo a continuidade dos negócios. A solução preserva relacionamentos entre registros de bancos de dados estruturados e seus LOBs correspondentes por meio de organização baseada em chave primária no Amazon S3, permitindo integridade referencial e ao mesmo tempo proporcionando flexibilidade de armazenamento de objetos para arquivos grandes.
• Vantagens arquitetônicas – Armazenar LOBs no Amazon S3 enquanto mantém dados estruturados no Aurora compatível com PostgreSQL cria uma separação clara. Essa arquitetura simplifica suas operações de backup e recuperação, melhora o desempenho de consultas em dados estruturados e fornece padrões de acesso flexíveis para objetos binários por meio do Amazon S3.

Melhores práticas de implementação

Considere as seguintes práticas recomendadas ao implementar esta solução:

• Comece pequeno e aumente gradualmente – Para implementar esta solução, comece com um projeto piloto usando dados que não sejam de produção para validar sua abordagem antes de se comprometer com a migração em grande escala. Isso lhe dá a oportunidade de resolver problemas em um ambiente controlado e refinar sua configuração sem impactar os sistemas de produção.
• Monitoramento – Configure um monitoramento abrangente por meio de Amazon CloudWatch para rastrear métricas importantes como atraso de Kafka, erros de função Lambda e latência de replicação. Estabeleça limites de alerta antecipadamente para que você possa detectar e resolver problemas rapidamente, antes que eles afetem seu cronograma de migração. Dimensione seu cluster MSK com base no quantity CDC esperado e configure a simultaneidade reservada do Lambda para lidar com picos de carga durante a sincronização inicial de dados.
• Segurança – Para segurança, use criptografia em trânsito e em repouso para dados estruturados e LOBs e siga o princípio do menor privilégio ao configurar Gerenciamento de identidade e acesso da AWS (IAM) para seu cluster MSK, funções Lambda, buckets S3 e instâncias de banco de dados. Documente seus mapeamentos de esquema entre Oracle e Aurora compatíveis com PostgreSQL, incluindo como os registros do banco de dados se vinculam aos seus LOBs correspondentes no Amazon S3.
• Teste e preparação – Antes de entrar em operação, teste minuciosamente seus procedimentos de failover e recuperação. Valide cenários como falhas de função Lambda, problemas de cluster MSK e problemas de conectividade de rede para garantir que você esteja preparado para possíveis problemas. Por fim, lembre-se de que essa arquitetura de streaming mantém a consistência eventual entre os sistemas de origem e de destino, portanto, pode haver breves atrasos durante períodos de alto quantity. Planeje sua estratégia de transição com isso em mente.

Limitações e considerações

Embora esta solução forneça uma abordagem robusta para migrar bancos de dados Oracle com LOBs para AWS, há diversas restrições inerentes que devem ser compreendidas antes da implementação.

Esta solução requer conectividade de rede entre o banco de dados Oracle de origem e o ambiente AWS. Para bancos de dados Oracle locais, você deve estabelecer AWS Direct Join ou VPN conectividade antes da implantação. A largura de banda da rede afeta diretamente a velocidade de replicação e o desempenho geral da migração, portanto, sua conexão deve ser capaz de lidar com o quantity esperado de eventos CDC e transferências LOB.

A solução usa o Debezium Connector for Oracle como conector de origem e o Debezium Connector for JDBC como conector de coletor. Essa arquitetura foi projetada especificamente para migrações Oracle para PostgreSQL. Outras combinações de bancos de dados exigem configurações de conector diferentes ou podem não ser suportadas pela implementação atual. A produtividade da migração também é limitada pela capacidade do cluster MSK e pelos limites de simultaneidade do Lambda. Você também pode exceder as cotas de serviço da AWS para migrações em grande escala e pode precisar solicitar aumentos de cota por meio do AWS Enterprise Assist.

Conclusão

Nesta postagem, apresentamos uma solução que aborda o desafio crítico de migrar seus grandes objetos binários da Oracle para a AWS usando uma arquitetura de streaming que separa o armazenamento LOB dos dados estruturados. Essa abordagem evita restrições de tamanho, reduz os custos de licenciamento da Oracle e preserva a integridade dos dados durante longos períodos de migração.

Pronto para transformar sua estratégia de migração Oracle? Visite o GitHub repositório, onde você encontrará o código completo de implantação do AWS CDK, arquivos de configuração e instruções passo a passo para começar.

Sobre os autores