En esta página se describen las prácticas recomendadas para los casos prácticos en los que:
- Los usuarios tienen una tabla en BigQuery y necesitan replicar sus datos mediante la captura de datos de cambios (CDC) en la misma tabla de BigQuery.
- Los usuarios deben copiar datos en una tabla de BigQuery sin usar la función de relleno de Datastream, ya sea por el tiempo que tardaría o por las limitaciones del producto.
Problema
Una tabla de BigQuery rellenada con la API Storage Write de BigQuery no permite operaciones normales del lenguaje de manipulación de datos (DML). Esto significa que, una vez que una secuencia de CDC empieza a escribir en una tabla de BigQuery, no hay forma de añadir datos históricos que no se hayan rellenado previamente en la tabla.
Veamos la siguiente situación:
- TIMESTAMP 1: se inicia la operación de copia de la tabla.
- TIMESTAMP 2: mientras se copia la tabla, las operaciones de DML en la fuente provocan cambios en los datos (se añaden, actualizan o eliminan filas).
- TIMESTAMP 3: se inicia la CDC, pero no se capturan los cambios que se produjeron en TIMESTAMP 2, lo que provoca una discrepancia en los datos.
Solución
Para asegurar la integridad de los datos, el proceso de CDC debe registrar todos los cambios que se hayan producido en la fuente desde el momento inmediatamente posterior a la última actualización que se haya copiado en la tabla de BigQuery.
La solución que se describe a continuación te permite asegurarte de que el proceso de CDC capture todos los cambios de TIMESTAMP 2 sin bloquear la operación de copia para que escriba datos en la tabla de BigQuery.
Requisitos previos
- La tabla de destino de BigQuery debe tener exactamente el mismo esquema y la misma configuración que si la hubiera creado Datastream. Para ello, puedes usar el kit de herramientas de migración de Datastream a BigQuery.
- En el caso de las fuentes MySQL y Oracle, el usuario debe poder identificar la posición del registro en el momento en que se inicia la operación de copia.
- La base de datos debe tener suficiente almacenamiento y una política de retención de registros que permita completar el proceso de copia de la tabla.
Fuentes MySQL y Oracle
- Crea el flujo que quieras usar para la replicación de CDC continua, pero no lo inicies. El flujo debe tener el estado CREATED.
- Cuando lo tengas todo listo para iniciar la operación de copia de la tabla, identifica la posición actual del registro de la base de datos:
- En el caso de MySQL, consulta la documentación de MySQL para saber cómo obtener las coordenadas del registro binario de replicación. Una vez que haya identificado la posición del registro, cierre la sesión para liberar los bloqueos de la base de datos.
- En Oracle, ejecuta la siguiente consulta:
SELECT current_scn FROM V$DATABASE
- Copia la tabla de la base de datos de origen en BigQuery.
- Una vez que se haya completado la operación de copia, sigue los pasos que se describen en la página Gestionar las secuencias para iniciar la secuencia desde la posición del registro que hayas identificado anteriormente.
Fuentes de PostgreSQL
- Cuando lo tengas todo listo para empezar a copiar la tabla, crea el espacio de replicación. Para obtener más información, consulta Configurar una base de datos PostgreSQL de origen.
- Copia la tabla de la base de datos de origen en BigQuery.
- Una vez que se haya completado la operación de copia, crea e inicia la emisión.