CDC em Tempo Real: PostgreSQL, MySQL, Oracle e SQL Server

Change Data Capture (CDC) é uma técnica que identifica e captura mudanças incrementais nos dados de um banco de dados em tempo real. Ao invés de comparar snapshots periódicos para encontrar diferenças, o CDC intercepta as próprias operações de escrita (INSERT, UPDATE, DELETE) no momento em que ocorrem, criando um stream contínuo de eventos de mudança.

O CDC é fundamental para a virtualização de dados porque elimina a necessidade de full scans periódicos para manter dSources sincronizados com a produção. Após a ingestão inicial (full sync), todas as atualizações subsequentes são capturadas via CDC, reduzindo o impacto na produção a praticamente zero.

A SOFI implementa CDC para os quatro principais bancos de dados relacionais, cada um utilizando o mecanismo nativo do banco para garantir confiabilidade e performance. Todos os eventos são normalizados para um formato unificado antes de serem processados pelo event store.

Cada evento CDC capturado segue um schema padronizado que inclui tipo de operação (INSERT, UPDATE, DELETE), schema e tabela afetados, dados novos e antigos, chave primária, LSN/SCN/GTID do banco de origem e identificador de transação. Essa normalização permite que o resto do pipeline trate eventos de qualquer banco de forma homogênea.

O PostgreSQL oferece replicação lógica nativa a partir da versão 10, baseada no Write-Ahead Log (WAL). A SOFI configura um logical replication slot que recebe todas as mudanças em formato decodificado, sem impacto perceptível na performance do banco de produção.

O setup requer que o parâmetro wal_level esteja configurado como 'logical' no postgresql.conf. A SOFI cria automaticamente uma publicação (CREATE PUBLICATION) para as tabelas monitoradas e consome as mudanças via protocolo de streaming replication. Em caso de desconexão, o slot retém as mudanças até que o consumer reconecte.

Uma vantagem do WAL lógico do PostgreSQL é a capacidade de filtrar mudanças por tabela ou até por coluna, reduzindo o volume de dados transmitidos. A SOFI utiliza essa capacidade para capturar apenas as tabelas relevantes para cada dSource, otimizando o throughput do pipeline.

O monitoramento do replication slot é crítico para evitar acúmulo de WAL no servidor de produção. A SOFI monitora continuamente o lag do slot e emite alertas quando o atraso ultrapassa thresholds configuráveis. Em caso de desconexão prolongada, o sistema pode optar por descartar o slot e refazer um full sync para evitar impacto no storage do servidor de origem.

A partir do PostgreSQL 15, a SOFI também suporta logical replication com filtro por coluna, enviando apenas as colunas necessárias para o dSource. Isso é particularmente útil quando tabelas contêm BLOBs grandes (imagens, documentos) que não são relevantes para os VDBs de teste, reduzindo significativamente o volume de dados transmitidos pelo pipeline de CDC.

O MySQL utiliza o binary log (binlog) como mecanismo de replicação, e a SOFI se conecta como um replica server para consumir os eventos de mudança. O binlog no formato ROW registra os valores antes e depois de cada operação, permitindo que a SOFI reconstrua o estado exato de cada linha modificada.

A configuração requer binlog_format=ROW e binlog_row_image=FULL no my.cnf, além de um usuário com privilégio REPLICATION SLAVE. A SOFI mantém controle da posição no binlog (file + position ou GTID) para garantir continuidade em caso de reconexão sem perder eventos.

Bancos compatíveis com MySQL, como MariaDB e TiDB, são suportados pelo mesmo mecanismo de CDC, já que implementam o protocolo de binlog de forma compatível. Isso permite que a SOFI capture mudanças nesses bancos sem necessidade de adaptações específicas.

Um cuidado importante com o binlog do MySQL é o gerenciamento de GTIDs (Global Transaction Identifiers). A SOFI utiliza GTIDs quando disponíveis para garantir exactly-once processing, evitando duplicação de eventos em cenários de failover onde o binlog file e position podem mudar entre réplicas.

Para o Oracle, a SOFI utiliza o LogMiner, que permite ler os redo logs e extrair operações DML em formato SQL. O LogMiner é configurado com supplemental logging ativado para garantir que todos os valores de coluna estejam disponíveis nos logs, não apenas as chaves primárias.

O Oracle LogMiner apresenta desafios únicos, como a necessidade de lidar com transações longas que podem spanning múltiplos redo logs e a gestão dos archived logs que precisam ser retidos enquanto houver eventos não processados. A SOFI gerencia isso automaticamente, rastreando o SCN (System Change Number) de cada transação.

No SQL Server, a SOFI utiliza o mecanismo nativo de CDC do banco, que cria tabelas de captura automaticamente quando habilitado para tabelas específicas. O SQL Server CDC armazena as mudanças em tabelas do sistema que a SOFI consome via polling otimizado, utilizando o LSN (Log Sequence Number) para controle de posição.

Uma particularidade do SQL Server CDC é que as tabelas de captura têm retenção configurável (padrão 3 dias). A SOFI gerencia essa retenção automaticamente e garante que todos os eventos sejam consumidos antes da expiração. Para ambientes com alto volume de transações, o intervalo de polling é ajustado dinamicamente para manter o lag abaixo de limites aceitáveis.

Para ambientes Oracle, um desafio adicional é o suporte a tipos de dados complexos como XMLType e JSON columns, que requerem tratamento especial durante a serialização dos eventos de CDC. A SOFI implementa wrappers de serialização que convertem esses tipos complexos para formatos portáveis, garantindo que os dados capturados possam ser restaurados fielmente em VDBs de qualquer engine.

Todos os eventos capturados pelos diferentes mecanismos de CDC são normalizados para um formato unificado no event store da SOFI. Cada evento contém o tipo de operação, o timestamp, a tabela afetada, os valores antes e depois da mudança e metadados de rastreamento como o transaction ID do banco de origem.

O event store permite que a SOFI crie snapshots incrementais. Ao invés de capturar todo o banco novamente, um snapshot incremental aplica apenas os eventos ocorridos desde o último snapshot ao bloco de dados existente, gerando novos blocos CoW apenas para os dados efetivamente modificados.

Esse mecanismo reduz drasticamente o tempo e o storage necessários para manter o histórico de snapshots. Um banco de 1TB com taxa de mudança diária de 2% gera snapshots incrementais de aproximadamente 20GB, permitindo manter semanas de histórico com custo de storage proporcional às mudanças reais e não ao tamanho total do banco.

A combinação de CDC em tempo real com snapshots incrementais permite que a SOFI ofereça Point-in-Time Recovery com granularidade de segundos, possibilitando que desenvolvedores criem VDBs que representam o estado exato do banco de produção em qualquer momento específico.

Operar pipelines de CDC em produção requer monitoramento robusto. A SOFI expõe métricas detalhadas como eventos processados por segundo, lag de replicação (diferença entre timestamp do evento e timestamp de processamento), tamanho da fila de eventos pendentes e taxa de erros de parsing.

Essas métricas alimentam o dashboard de CDC da plataforma e podem ser exportadas para sistemas de observabilidade externos via Prometheus endpoint. Alertas são configuráveis para cenários como lag superior a 5 minutos, taxa de erros acima de 0.1% ou fila de eventos crescendo continuamente, permitindo intervenção proativa antes que problemas impactem a qualidade dos dados nos VDBs.

Para troubleshooting, a SOFI mantém um log detalhado dos últimos N eventos processados com seus metadados completos. Isso permite diagnosticar rapidamente problemas como schemas inesperados, tipos de dados incompatíveis ou transações que causam parsing errors, sem necessidade de acessar diretamente os logs do banco de origem.

A arquitetura do CDC da SOFI também suporta transformações em tempo real nos eventos antes da persistência. Filtros podem ser configurados para ignorar tabelas de log ou temporárias, transformações podem anonimizar dados sensíveis no stream (antes mesmo da criação de snapshots) e roteamento condicional pode direcionar eventos de diferentes tabelas para pipelines de processamento distintos.

O módulo de replicação da SOFI estende o CDC para cenários de migração e sincronização entre bancos heterogêneos. Utilizando o pipeline de CDC como fonte, é possível replicar dados de um PostgreSQL para um MySQL ou de um Oracle para um Snowflake, com transformações de schema e tipo de dados aplicadas automaticamente durante o stream. Isso abre possibilidades para modernização de infraestrutura de dados com downtime mínimo.

A posição de cada consumer no stream de CDC é rastreada pelo position tracker, que armazena o último LSN/SCN/GTID processado com sucesso. Em caso de falha ou reinício do worker, o processamento retoma exatamente de onde parou, garantindo exactly-once semantics. O position tracker persiste o estado tanto em Redis (para leitura rápida) quanto no PostgreSQL (para durabilidade), implementando um padrão dual-write com reconciliação periódica.

Para cenários de alta disponibilidade, a SOFI suporta múltiplos workers CDC consumindo do mesmo stream com particionamento por tabela. Cada worker é responsável por um subconjunto de tabelas, distribuindo a carga de processamento. O Celery com Redis como broker coordena a atribuição de tabelas aos workers, com re-balanceamento automático quando workers são adicionados ou removidos do pool.