Change Data Capture no Guara Cloud

O Guara Cloud oferece dois serviços de catálogo complementares para mover dados entre sistemas em (quase) tempo real: o Debezium Server, para Change Data Capture (CDC) baseado em log a partir de bancos de dados, e o Conduit, para streaming de uso geral entre bancos, barramentos de mensagens e endpoints HTTP.

O que é CDC?

Change Data Capture — Captura de Dados Modificados — transforma as gravações que já estão acontecendo dentro do seu banco em um fluxo de eventos. Em vez de rodar um SELECT * noturno ou escrever hooks “after save” em cada serviço, uma engine de CDC lê o log de transações (o WAL do PostgreSQL, o binlog do MySQL, o oplog do MongoDB) e publica um evento estruturado para cada insert, update e delete.

A diferença prática: o CDC consome o mesmo log que o próprio banco usa para replicar para suas réplicas — então você captura cada mudança exatamente uma vez, em ordem de commit, com atraso próximo de zero e praticamente sem carga adicional na origem. Sempre que um pedido é inserido na sua tabela orders no PostgreSQL, um evento chega ao destino em uma fração de segundo — sem polling, sem dual writes, sem linhas perdidas em janela de migração.

Do lado consumidor, quem recebe o evento faz o que quiser com o stream: manter um índice de busca atualizado, invalidar caches por chave, espelhar gravações para uma base analítica, disparar notificações para um webhook, hidratar um read model. O banco de origem não sabe e não precisa saber que isso existe.

Debezium vs Conduit

Ambos rodam como um pod por pipeline, ambos fazem bridge das credenciais de serviços sibling automaticamente, e ambos disponibilizam uma aba Insights. A diferença está no formato dos problemas que cada um resolve melhor.

Se você quer…	Escolha
CDC de PostgreSQL, MySQL ou MongoDB para NATS, Kafka ou HTTP	Debezium
Runtime Go leve, sem JVM, rodando inclusive no plano Hobby	Conduit
Transmitir a partir de uma origem não relacional (subject NATS, endpoint HTTP)	Conduit
Sincronização cross-database (por exemplo, Postgres para MySQL)	Conduit
Remover campos PII com um processador in-line	Conduit
Snapshot e streaming bem testados em um OLTP de produção	Debezium
Destino Apache Kafka com SASL/SSL pass-through	Qualquer um

Regra simples: se o problema é “tenho um banco e quero cada mudança de linha como evento”, o Debezium é o default consagrado. Se o problema é “tenho um pipeline entre dois sistemas, e um deles pode nem ser um banco”, use o Conduit.

Matriz de origens e destinos

As duas engines cobrem terrenos parecidos, mas não idênticos.

	Debezium	Conduit
Origem: PostgreSQL	Sim (WAL lógico, pgoutput)	Sim (WAL lógico, connector built-in)
Origem: MySQL	Sim (binlog, formato ROW)	Sim (connector standalone)
Origem: MongoDB	Sim (oplog, replica set)	Não na v1 — use o Debezium
Origem: NATS JetStream	Não	Sim (connector standalone)
Origem: HTTP	Não	Sim (connector standalone)
Destino: NATS JetStream	Sim	Sim
Destino: Apache Kafka	Sim (externo)	Sim (connector built-in)
Destino: PostgreSQL	Não	Sim
Destino: MySQL	Não	Sim
Destino: webhook HTTP	Sim	Sim

Modos de vínculo: sibling vs externo

Nos dois serviços você pode apontar cada lado do pipeline (origem e destino) para:

• Serviço sibling do catálogo — o wizard exibe um picker listando todos os serviços de catálogo já implantados neste projeto que são compatíveis. Credenciais, host, porta, banco e URL são injetados no pod de CDC como variáveis de ambiente BRIDGED_SOURCE_* / BRIDGED_SINK_* automaticamente — não há nada para colar.
• URL externa — você cola uma URL completa mais usuário e senha. Útil para uma instância RDS fora do Guara, um Kafka gerenciado, um webhook próprio ou qualquer outro sistema fora da plataforma. Os valores caem em um Secret por serviço e chegam ao pod como variáveis SOURCE_EXTERNAL_* / SINK_EXTERNAL_*.

Você pode misturar modos à vontade: sibling na origem e externo no destino, externo na origem e sibling no destino, ou os dois lados externos. Os dois lados nunca se enxergam por meios internos do Guara — só enxergam as variáveis de ambiente injetadas pelo orchestrator.

Pré-requisitos

PostgreSQL sibling

O PostgreSQL gerenciado do Guara já vem pronto para CDC:

• wal_level=logical é ativado na inicialização.
• O role dbuser recebe o atributo REPLICATION no init.

Basta fazer deploy do PostgreSQL pelo catálogo e, em cima dele, do Debezium ou do Conduit — não há passos extras. Serviços PostgreSQL do catálogo já existentes passam a adotar essas configurações após o próximo restart do pod.

PostgreSQL externo

Fora do Guara, o DBA precisa configurar a origem antes de apontar o pipeline:

• Definir wal_level=logical no postgresql.conf (exige restart do servidor).
• Criar um role com os atributos LOGIN e REPLICATION: CREATE ROLE cdc_user LOGIN REPLICATION PASSWORD '...';.
• Conceder SELECT nas tabelas que você quer capturar, além de CREATE no banco para que a engine consiga criar a publicação.

MySQL externo

• Habilitar o binary log em formato row: log_bin=ON, binlog_format=ROW, binlog_row_image=FULL.
• Criar um usuário com REPLICATION SLAVE, REPLICATION CLIENT e SELECT nas tabelas capturadas.
• Manter binlog_expire_logs_seconds alto o suficiente para o pipeline conseguir recuperar o atraso após um restart.

MongoDB externo (apenas Debezium)

• A origem precisa ser um replica set (um replica set de um nó é suficiente para desenvolvimento) — o acesso ao oplog só existe em replica sets.
• Forneça um usuário com permissão read nos bancos capturados e clusterMonitor para o Debezium enxergar os shards.

Lado do destino

• NATS JetStream (sibling): nada a configurar — o NATS gerenciado do Guara já expõe as credenciais que Debezium e Conduit precisam, e o bridge cuida do resto.
• Apache Kafka (externo): cole a URL de bootstrap-servers e as credenciais SASL (usuário e senha); SSL é negociado se o broker anunciar suporte.
• Webhook HTTP: cole a URL completa; o usuário e senha fornecidos são enviados como basic-auth em cada requisição.

Começando

O caminho mais curto entre “nada” e um stream funcionando:

1. Primeiro faça deploy dos serviços de origem e destino do catálogo. No fluxo típico, você implanta um serviço PostgreSQL (origem) e um serviço NATS (destino) pelo catálogo e espera os dois chegarem a Running.
2. Implante o Debezium ou o Conduit. No wizard, escolha o modo sibling nos dois lados, selecione o serviço Postgres como origem e o serviço NATS como destino. Use o campo tableFilter se quiser limitar a captura a algumas tabelas.
3. Verifique. Abra a aba Insights do novo serviço — em até um minuto o painel de replication lag (Debezium) ou de throughput (Conduit) deve mostrar um valor diferente de zero. Insira uma linha no PostgreSQL e acompanhe a chegada do evento no subject NATS configurado.

Próximos passos