Migrar una tabla de CDC a otra región

En esta página se describen las prácticas recomendadas para un caso práctico en el que ha configurado la replicación de Datastream en BigQuery, pero ha configurado el conjunto de datos de destino en una región incorrecta. Después, 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 empezar

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

  • La migración lleva tiempo y debes pausar temporalmente la emisión durante la operación. Para mantener la integridad de los datos, la base de datos de origen debe conservar los registros de cambios cuando se pausa el flujo. Para estimar cuánto tiempo debe pausar el flujo, combine el valor de max_staleness del conjunto de datos y la operación de combinación de mayor duración:
    • Para obtener información sobre el tiempo que pueden tardar en completarse las operaciones de combinación, consulta el valor de max_staleness de la tabla recomendada.
    • Para encontrar el max_staleness máximo del conjunto de datos, consulta el artículo Determinar el valor actual de max_staleness de una tabla y ajusta la consulta a tus necesidades específicas.
    • Si la pausa estimada es demasiado larga para que la admita tu base de datos de origen, puede que te interese reducir temporalmente el valor de max_staleness en las tablas del conjunto de datos.
  • Verifica que el usuario que realiza la migración tenga suficientes recursos de BigQuery 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 reservas.
  • Verifica que el usuario que realiza la migración tenga permisos suficientes para llevar a cabo esta operación, como los controles de Gestión de Identidades y Accesos (IAM) o Controles de Servicio de VPC.

Pasos de 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.

    Ir a BigQuery Studio

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

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

    Haz los cambios siguientes:

    • DATASET_NAME: el nombre del conjunto de datos que quieras crear.
    • NEW_REGION: el nombre de la región en la que quieras crear el conjunto de datos. Por ejemplo, region-us.
  3. Monitoriza el progreso de la migración y espera hasta que la marca de agua de la copia de la réplica esté a pocos minutos de la principal. Puedes ejecutar esta consulta en INFORMATION_SCHEMA de BigQuery para comprobar 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;
    

    Haz los cambios siguientes:

    • PROJECT_ID: el ID de tu proyecto de Google Cloud .
    • DATASET_NAME: el nombre de tu conjunto de datos.
    • DATASET_REPLICA_STALENESS: la configuración de obsolescencia de las tablas de la réplica del conjunto de datos que ha creado.
    • NEW_REGION: la región en la que has creado el conjunto de datos.
  4. Pausa el flujo de Datastream. Para obtener más información, consulta Pausar la emisión.

  5. Espera a que se agote el flujo y anota la hora en la que el flujo entró en el estado PAUSED.

  6. Para confirmar que se han aplicado los últimos cambios de los CDC a la tabla de BigQuery, consulta el upsert_stream_apply_watermark de la tabla. Ejecuta la siguiente consulta y comprueba que la marca de agua tiene una marca de tiempo 10 minutos posterior a la hora en la que se pausó la emisión:

    SELECT table_name, upsert_stream_apply_watermark
    FROM DATASET_NAME.INFORMATION_SCHEMA.TABLES
    

    Para ejecutar la consulta solo en una tabla específica, añade la siguiente cláusula WHERE:

    WHERE table_name = 'TABLE_NAME'
    

    Haz los cambios siguientes:

    • DATASET_NAME: el nombre de tu conjunto de datos.
    • TABLE_NAME: opcional. La tabla de la que quieres consultar 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 es posterior a la upsert_stream_apply_watermark capturada en el paso 6.

  8. También puede comparar manualmente varias tablas del conjunto de datos principal de la región original con la réplica de la nueva región para verificar que todos los datos se hayan copiado correctamente.

  9. Promocione la réplica del conjunto de datos de BigQuery ejecutando el siguiente comando en BigQuery Studio:

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

    Haz los cambios siguientes:

    • DATASET_NAME: el nombre de tu conjunto de datos.
    • NEW_REGION: la región en la que has creado el conjunto de datos.
  10. Si ya no necesitas el conjunto de datos original (ahora la réplica) y no quieres incurrir en costes adicionales, ve a BigQuery Studio y elimina el conjunto de datos de BigQuery original:

    ALTER SCHEMA DATASET_NAME DROP REPLICA IF EXISTS ORIGINAL_REGION;
    

    Haz los cambios siguientes:

    • DATASET_NAME: el nombre del conjunto de datos original.
    • ORIGINAL_REGION: la región del conjunto de datos original.
  11. Crea un nuevo flujo con la misma configuración, pero con una nueva ubicación de destino de BigQuery.

  12. Inicia la nueva emisión.

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

    • En el caso de las fuentes MySQL y Oracle, puedes identificar la posición del registro examinando los registros del flujo original y buscando la última posición desde la que el flujo se ha leído correctamente. Para obtener información sobre cómo iniciar la emisión desde una posición específica, consulta Gestionar emisiones.
    • En el caso de las fuentes de PostgreSQL, el nuevo flujo empieza a leer los cambios desde el primer número de secuencia de registro (LSN) del espacio de replicación. Como es posible que la secuencia original ya haya procesado algunos de estos cambios, cambie manualmente el puntero de la ranura de replicación al último LSN desde el que ha leído Datastream. Puede encontrar este LSN en los registros de consumidor de Datastream.
  13. Si quieres, elimina la emisión original.