Cómo migrar una tabla de CDC a otra región

En esta página, se describen las prácticas recomendadas para un caso de uso en el que configuraste la replicación de Datastream en BigQuery, pero configuraste el conjunto de datos de destino en una región incorrecta. Luego, quieres mover el conjunto de datos a otra región (o multirregión) sin tener que volver a sincronizar todos los datos de la base de datos de origen con BigQuery.

Antes de comenzar

Antes de comenzar a migrar tus datos a otra región, ten en cuenta lo siguiente:

  • La migración lleva tiempo y debes pausar temporalmente la transmisión durante la operación. Para mantener la integridad de los datos, la base de datos de origen debe retener los registros de cambios cuando se pausa la transmisión. Para estimar durante cuánto tiempo se debe pausar la transmisión, combina el valor de max_staleness en el conjunto de datos y la operación de combinación de mayor duración:
    • Para obtener información sobre cuánto tiempo pueden tardar en completarse las operaciones de combinación, consulta Valor recomendado de la tabla max_staleness.
    • Para encontrar el max_staleness máximo en el conjunto de datos, consulta Determina el valor actual de max_staleness de una tabla y ajusta la consulta según tus necesidades específicas.
    • Si la pausa estimada es demasiado larga para que la base de datos de origen la admita, considera reducir temporalmente el valor de max_staleness para las tablas del conjunto de datos.
  • Verifica que el usuario que realiza la migración tenga recursos de BigQuery suficientes en la región de destino (reserva de consultas y reserva en segundo plano). Para obtener más información sobre las reservas, consulta Asignaciones de reserva.
  • Verifica que el usuario que realiza la migración tenga permisos suficientes para realizar esta operación, como los controles de Identity and Access Management (IAM) o los Controles del servicio de VPC.

Pasos para la migración

Para iniciar la migración de conjuntos de datos, usa la replicación de datos de BigQuery:

  1. En la Google Cloud consola, ve a la página BigQuery Studio.

    Ve a BigQuery Studio

  2. Crea una réplica del conjunto de datos de BigQuery en la región nueva:

    ALTER SCHEMA DATASET_NAME
ADD REPLICA 'NEW_REGION'
OPTIONS(location='NEW_REGION');

    Reemplaza lo siguiente:

    • DATASET_NAME: Es el nombre del conjunto de datos que deseas crear.
    • NEW_REGION: Es el nombre de la región en la que deseas crear tu conjunto de datos. Por ejemplo, region-us

  3. Supervisa el progreso de la migración y espera a que la marca de agua de la copia en la réplica esté a pocos minutos de la principal. Puedes ejecutar esta consulta en INFORMATION_SCHEMA de BigQuery para verificar el progreso de la migración:

    SELECT
catalog_name as project_id,
schema_name as dataset_name,
replication_time as dataset_replica_staleness
FROM
'NEW_REGION'.INFORMATION_SCHEMA.SCHEMATA_REPLICAS
WHERE
catalog_name = PROJECT_ID
AND schema_name = DATASET_NAME
AND location = NEW_REGION;

    Reemplaza lo siguiente:

    • PROJECT_ID: Es el ID de tu Google Cloud proyecto.
    • DATASET_NAME: es el nombre de tu conjunto de datos.
    • DATASET_REPLICA_STALENESS: Es la configuración de inactividad de las tablas en la réplica del conjunto de datos que creaste.
    • NEW_REGION: Es la región en la que creaste el conjunto de datos.

  4. Pausa el flujo de Datastream existente. Para obtener más información, consulta Cómo pausar la transmisión.

  5. Espera a que se agote la transmisión y toma nota de la hora en la que la transmisión ingresó al estado PAUSED.

  6. Para confirmar que los cambios más recientes de la CDC se aplicaron a la tabla de BigQuery, verifica el upsert_stream_apply_watermark de la tabla. Ejecuta la siguiente consulta y asegúrate de que la marca de tiempo de la marca de agua sea 10 minutos después de la hora en que se detuvo la transmisión:

    SELECT table_name, upsert_stream_apply_watermark
FROM DATASET_NAME.INFORMATION_SCHEMA.TABLES

    Para ejecutar la consulta solo para una tabla específica, agrega la siguiente cláusula WHERE:

    WHERE table_name = 'TABLE_NAME'

    Reemplaza lo siguiente:

    • DATASET_NAME: es el nombre de tu conjunto de datos.
    • TABLE_NAME: es opcional. Es la tabla para la que deseas verificar el upsert_stream_apply_watermark.

  7. Usa la consulta del paso 3 para verificar que la marca de agua de la copia de la región nueva sea posterior a la upsert_stream_apply_watermark capturada en el paso 6.

  8. De manera opcional, compara manualmente varias tablas del conjunto de datos principal en la región original con la réplica en la región nueva para verificar que todos los datos se hayan copiado correctamente.

  9. Ejecuta el siguiente command en BigQuery Studio para promocionar la réplica del conjunto de datos de BigQuery:

    ALTER SCHEMA DATASET_NAME
SET OPTIONS(primary_replica = 'NEW_REGION');

    Reemplaza lo siguiente:

    • DATASET_NAME: es el nombre de tu conjunto de datos.
    • NEW_REGION: Es la región en la que creaste el conjunto de datos.

  10. De manera opcional, si ya no necesitas el conjunto de datos original (ahora la réplica) y no quieres incurrir en cargos adicionales, ve a BigQuery Studio y suelta el conjunto de datos de BigQuery original:

    ALTER SCHEMA DATASET_NAME DROP REPLICA IF EXISTS ORIGINAL_REGION;

    Reemplaza lo siguiente:

    • DATASET_NAME: El nombre del conjunto de datos original.
    • ORIGINAL_REGION: La región del conjunto de datos original.

  11. Crea un flujo nuevo con la misma configuración, pero con una nueva ubicación de destino de BigQuery.

  12. Inicia la nueva transmisión.

    Para evitar replicar eventos duplicados, inicia la transmisión desde una posición específica:

    • En el caso de las fuentes de MySQL y Oracle, puedes identificar la posición del registro examinando los registros de la transmisión original y encontrando la última posición desde la que se leyó correctamente. Para obtener información sobre cómo iniciar la transmisión desde una posición específica, consulta Cómo administrar transmisiones.
    • Para las fuentes de PostgreSQL, el flujo nuevo comienza a leer los cambios desde el primer número de secuencia de registro (LSN) en la ranura de replicación. Dado que es posible que el flujo original ya haya procesado algunos de estos cambios, cambia manualmente el puntero de la ranura de replicación al último LSN del que leyó Datastream. Puedes encontrar este LSN en los registros del consumidor de Datastream.

  13. De manera opcional, borra la transmisión original.