CDC com Debezium: change data capture sério
⏱ 13 min·⭐ 55 XP
Pré-requisitos (0/1)0%
- ⬜🏛️ Data lake vs lakehouse vs warehouse(Data Engineering Moderna)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Setup Debezium + Postgres
# 1. Enable logical replication no Postgres
# postgresql.conf:
wal_level = logical
max_replication_slots = 4
max_wal_senders = 4
# 2. Create publication
CREATE PUBLICATION debezium_pub FOR ALL TABLES;
# 3. Criar replication slot (Debezium faz automático, ou manual)
SELECT pg_create_logical_replication_slot('debezium_slot', 'pgoutput');
# 4. Debezium config (Kafka Connect)
{
"name": "pg-connector",
"config": {
"connector.class": "io.debezium.connector.postgresql.PostgresConnector",
"database.hostname": "postgres",
"database.dbname": "mydb",
"plugin.name": "pgoutput",
"slot.name": "debezium_slot",
"publication.name": "debezium_pub",
"topic.prefix": "pg-prod",
"table.include.list": "public.orders,public.users"
}
}Banco de origem
Tabelaa aplicação escreve normalmente
Log de escritatoda mudança já passa por aqui
Slot de replicaçãomarca até onde o consumidor leu
Captura
Conector de CDCfinge ser uma réplica do banco
Transporte
Tópico por tabelaantes, depois e tipo da operação
Destinos
Camada crua
Índice de busca
Cache
A alternativa que se evita
Varredura periódicaperde exclusões e mudanças intermediárias
- → lê o log
- → posição
- → o que NÃO fazer
- Banco de dados
- Conceito de arquitetura
- Analytics
A seta pontilhada da varredura periódica aponta para a tabela; a da captura aponta para o log. Toda a diferença está aí: uma pergunta ao banco o que mudou e perde o que aconteceu entre duas perguntas; a outra lê o registro do que aconteceu, na ordem em que aconteceu.
- 1 · O log já existe. O banco grava toda alteração num log antes de aplicá-la — é assim que ele sobrevive a queda de energia e alimenta réplicas. A captura apenas se apresenta como mais um leitor desse log.
- 2 · Nenhuma carga extra de consulta. Varrer a tabela a cada minuto compete com a aplicação por E/S e trava linhas. Ler o log não toca na tabela: o custo no banco de origem é próximo de zero.
- 3 · O slot guarda até onde já foi lido. É o que garante retomar sem perder eventos depois de uma queda. E é também a armadilha operacional: consumidor parado faz o banco reter log indefinidamente até o disco encher.
- 4 · O evento carrega antes e depois. Não é só "a linha mudou": vêm o estado anterior, o novo e a operação. Isso é o que permite ao destino aplicar exclusão e reconstruir histórico — coisa que a varredura periódica jamais entrega.
- 5 · Um evento, vários destinos. Índice de busca, camada crua e cache passam a se atualizar a partir da mesma fonte, sem que a aplicação escreva em cada um. É o que remove a escrita dupla e a inconsistência que ela sempre produz.
Event exemplo
// Topic: pg-prod.public.orders
{
"before": null, // INSERT (null) / UPDATE (pre) / DELETE (pre)
"after": { "id": 1, "total": 100 }, // INSERT/UPDATE (post) / DELETE (null)
"source": {
"ts_ms": 1735689600000,
"db": "mydb",
"schema": "public",
"table": "orders",
"lsn": 123456789
},
"op": "c", // c=create, u=update, d=delete, r=read(snapshot)
"ts_ms": 1735689600050
}💡
Alternativas gerenciadas: AWS DMS (mais limitado), Fivetran (SaaS caro), Airbyte (open source, menos features que Debezium mas mais DX). Debezium é padrão-ouro pra auto-hosted serious.
Quiz rápido
Por que ler o log de transações é melhor que consultar periodicamente a tabela?
Perguntas frequentes
❓ O que captura de mudança resolve?
Levar alteração do banco operacional para outros sistemas sem consultar periodicamente e sem alterar a aplicação: ela lê o registro de transações e publica cada inserção, atualização e exclusão. É o que permite manter cópia analítica atualizada sem sobrecarregar o banco de origem.
❓ Captura de mudança ou consulta periódica por timestamp?
Captura quando exclusão importa, quando a latência precisa ser baixa ou quando a consulta periódica pesaria no banco. Consulta por timestamp é mais simples e perde exclusão e alteração intermediária. A perda de exclusão é o defeito que ninguém nota até o relatório contar registro que não existe.
❓ Qual o maior risco de operar captura de mudança?
A retenção do registro de transações: se o consumidor para por tempo suficiente, o registro necessário é descartado e a única saída é recarga completa. Monitorar a defasagem do consumidor é obrigatório, e é o que separa quem opera isso de quem só configurou.
Fixando
Quiz rápido
Qual garantia de entrega esse tipo de captura normalmente oferece, e o que isso exige do consumidor?
Quiz rápido
Qual é o desafio ao iniciar a captura numa tabela que já tem dados?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…