O que é change data capture, e como o CDC baseado em log difere de fazer polling em uma coluna de timestamp?

Change data capture transmite mudanças em nível de linha para fora de um banco de origem. O CDC baseado em log lê o log de transações diretamente, então captura inserts, updates e deletes físicos na ordem de commit e quase sem carga na origem. Fazer polling em uma coluna updated_at é mais simples, mas perde deletes físicos, perde estados intermediários entre coletas, depende da aplicação manter a coluna e pode perder linhas por problemas de relógio ou de fronteira de transação.

CDC trata de obter mudanças em nível de linha em vez de reler tabelas inteiras. O CDC baseado em log, com algo como o Debezium lendo o write ahead log do Postgres ou o binlog do MySQL, entrega cada insert, update e delete na ordem de commit e coloca quase nenhuma carga de consulta no primário. Fazer polling em uma coluna updated_at é muito mais fácil de configurar, e serve bem para dados de referência que mudam devagar, mas tem buracos reais. Ele não enxerga deletes físicos de jeito nenhum, então as linhas persistem silenciosamente lá na frente para sempre. Perde estados intermediários se uma linha muda duas vezes entre coletas, e depende de todo escritor lembrar de preencher a coluna, o que um job legado no nosso parque nunca fazia. O CDC baseado em log tem o seu próprio custo operacional. Você precisa de um replication slot, e se o seu consumidor travar o log não é recuperado e o disco da origem enche, o que é uma falha genuinamente perigosa. Então eu monitoro o lag do slot como alerta de primeira classe, junto com o lag do pipeline.