La captura de datos modificados (CDC) basada en el registro binario (binlog) de MySQL soluciona las carencias de los sincronizadores periódicos: elimina puntos ciegos en borrados y actualizaciones intermedias, y reduce la carga sobre la base de datos de producción. Un job programado con SELECT solo ve el estado actual de cada fila; no detecta registros borrados entre dos ejecuciones ni los cambios intermedios cuando una fila se actualiza varias veces. CDC, en cambio, lee directamente del binlog en formato ROW con imágenes completas, registrando cada INSERT, UPDATE y DELETE en orden y con el estado íntegro de la fila, sin inferencias.
Para habilitarlo, MySQL requiere varios ajustes: binlog_format en ROW, binlog_row_image en FULL (para que UPDATE y DELETE transporten el estado completo antes y después) y binlog_row_value_options sin PARTIAL_JSON, ya que este último solo registra los cambios dentro de columnas JSON. El usuario de replicación necesita privilegios REPLICATION SLAVE, REPLICATION CLIENT, SELECT, RELOAD y SHOW DATABASES, además de un server-id único para evitar colisiones silenciosas con otras réplicas. También conviene ampliar la retención del binlog más allá del periodo de inactividad previsto, pues tras la purga el CDC necesitará rehacer la snapshot inicial.
En el destino, cada evento del binlog se mapea a una operación de fila en BigQuery. La clave no es la velocidad de carga, sino garantizar que los datos lleguen íntegros: un pipeline que entrega datos incompletos puntualmente resulta peor que otro con minutos de retraso pero siempre correcto. Plataformas gestionadas como Erathos automatizan la elección del modo de snapshot, la asignación de server-id y la lógica de recuperación tras la purga del binlog.