CDC do MySQL para o BigQuery: Guia Prático de Configuração

A maioria dos pipelines de MySQL pro warehouse roda no mesmo padrão: um job agendado seleciona linhas, compara com o que tinha antes, e grava a diferença. Funciona, até não funcionar mais.

O que sincronizações periódicas não veem

Um sync baseado em SELECT só vê o que existe agora. Não tem como saber que uma linha existiu e foi deletada entre duas execuções, não vê estados intermediários de uma linha que mudou mais de uma vez, e ainda coloca carga real no seu banco de produção toda vez que varre uma tabela grande só pra achar um punhado de linhas que mudaram. Já cobrimos esse comparativo com mais profundidade no artigo sobre sync por cursor vs Change Data Capture.

O que o CDC faz diferente

Captura de mudanças (CDC) lê direto do binlog do MySQL, o mesmo mecanismo que o MySQL usa internamente pra replicação. Cada INSERT, UPDATE e DELETE é capturado no momento em que é escrito no log, na ordem, com o estado completo da linha. Nada é inferido por comparação. Nada depende de quando um job em batch resolve rodar.

Isso não é sobre velocidade. Um pipeline de CDC que roda de hora em hora ainda é fundamentalmente mais confiável que um sync em batch que roda a cada minuto, porque ele captura tudo que aconteceu, não só o último snapshot.

O que precisa estar configurado no MySQL

CDC via binlog tem pré-requisitos reais:

1. Binary logging em formato ROW, com row image FULL. Se binlog_row_image não estiver como FULL, eventos de DELETE e UPDATE não carregam o estado completo antes/depois da linha, só o necessário pra aplicar a mudança. Muitas vezes isso não é suficiente pra quem consome esse dado do outro lado.
2. binlog_row_value_options não pode estar como PARTIAL_JSON. Se estiver, updates em colunas JSON só gravam o que mudou dentro do JSON, não o valor completo. Silencioso, fácil de passar batido até comparar com a origem.
3. O usuário de replicação precisa das permissões REPLICATION SLAVE e REPLICATION CLIENT pra ler e monitorar o binlog, além de SELECT, RELOAD e SHOW DATABASES pro snapshot inicial.
4. Um server-id único pra cada cliente de replicação conectado ao banco, incluindo sua conexão de CDC. Colisão com réplicas existentes causa falha silenciosa e dolorida de debugar.
5. Retenção de binlog suficiente pra cobrir qualquer período offline. O MySQL apaga arquivos de binlog depois de uma janela configurável (30 dias por padrão). Se sua conexão de CDC ficar offline mais tempo que isso, ela não consegue retomar de onde parou. Vai precisar de um snapshot inicial novo.

Configurando

GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'seu_usuario';
FLUSH PRIVILEGES;

Depois confirme a configuração do binlog:

SHOW VARIABLES LIKE 'log_bin';
SHOW VARIABLES LIKE 'binlog_format';
SHOW VARIABLES LIKE 'binlog_row_image';

Se algum desses não estiver correto, ajusta no my.cnf, e o MySQL precisa reiniciar pra aplicar.

A documentação completa do conector, incluindo todos os pré-requisitos e troubleshooting, está em docs.erathos.com/connectors/databases/mysql#cdc-setup.

É aqui que uma plataforma gerenciada compensa o esforço. A Erathos e ferramentas parecidas cuidam da escolha do modo de snapshot (cópia inicial completa ou só binlog), da atribuição de server-id evitando colisão, e da lógica de recuperação quando um binlog é apagado antes da conexão conseguir ler, pra quem opera o pipeline não precisar reconstruir essa lógica na mão toda vez que conecta uma fonte nova. Os custos ocultos de manter isso por conta própria costumam aparecer só alguns meses depois, quando o pipeline caseiro vira projeto de manutenção permanente.

Levando pro BigQuery

Com o CDC capturando as mudanças corretamente, o lado do destino é comparativamente simples: cada evento de mudança vira uma operação de linha nas suas tabelas do BigQuery. A parte que vale a pena acertar não é a carga no BigQuery, é garantir que o que chega lá está completo. Se o custo de armazenamento e consulta no BigQuery também for uma preocupação à parte, este guia de otimização de custos cobre isso em detalhe. Um pipeline que entrega dado incompleto na hora certa é pior que um que às vezes atrasa alguns minutos, mas nunca está errado.

Se o seu time ainda roda sync completo em batch contra o MySQL de produção, a pergunta que vale a pena fazer não é "como deixar isso mais rápido". É "o que a gente hoje não consegue ver".

Se quiser testar isso na prática, dá pra criar uma conta na Erathos e conectar seu MySQL com CDC habilitado em poucos minutos.