Migrer une table CDC vers une autre région

Vous pouvez déplacer un ensemble de données de destination Datastream vers une autre région ou multirégion BigQuery à l'aide de la réplication interrégionale d'ensembles de données. Ce workflow met à jour l'emplacement d'un ensemble de données de capture des données modifiées (CDC) actif tout en minimisant les temps d'arrêt du flux et en évitant un remplissage historique complet à partir de votre base de données source.

Pendant la migration, l'interrogation de la région secondaire peut renvoyer des résultats incomplets ou inexacts. Pour en savoir plus sur les limites de la migration, consultez la page Réplication interrégionale d'ensembles de données.

Avant de commencer

Avant de commencer à migrer vos données vers une autre région, tenez compte des points suivants :

  • La migration prend du temps et vous devez suspendre temporairement le flux pendant l'opération. Pour maintenir l'intégrité des données, la base de données source doit conserver les journaux de modifications lorsque le flux est suspendu. Pour estimer la durée de suspension du flux, combinez la valeur de max_staleness dans l'ensemble de données et l'opération de fusion la plus longue :
    • Pour savoir combien de temps les opérations de fusion peuvent prendre, consultez la section Valeur max_staleness recommandée pour la table.
    • Pour trouver la valeur max_staleness maximale dans l'ensemble de données, consultez la section Déterminer la valeur max_staleness actuelle d'une table et ajustez la requête en fonction de vos besoins spécifiques.
    • Si la suspension estimée est trop longue pour que votre base de données source la prenne en charge, vous pouvez envisager de réduire temporairement la valeur de max_staleness pour les tables de l'ensemble de données.
  • Vérifiez que l'utilisateur qui effectue la migration dispose de suffisamment de ressources BigQuery dans la région de destination (réservation de requêtes et réservation en arrière-plan). Pour en savoir plus sur les réservations, consultez la section Attributions de réservations.
  • Vérifiez que l'utilisateur qui effectue la migration dispose des autorisations suffisantes pour effectuer cette opération, telles que les contrôles Identity and Access Management (IAM) ou VPC Service Controls.

Procédure de migration

Pour lancer la migration d'un ensemble de données, utilisez la réplication de données BigQuery :

  1. Dans la Google Cloud console, accédez à la page BigQuery Studio.

    Accéder à BigQuery Studio

  2. Créez une instance répliquée d'ensemble de données BigQuery dans la nouvelle région :

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

    Remplacez les éléments suivants :

    • DATASET_NAME : nom de l'ensemble de données que vous souhaitez créer.
    • NEW_REGION : nom de la région dans laquelle vous souhaitez créer votre ensemble de données. Exemple : region-us.

  3. Surveillez la progression de la migration et attendez que le filigrane de copie de l'instance répliquée soit à quelques minutes de celui de l'instance principale. Vous pouvez exécuter cette requête sur BigQuery INFORMATION_SCHEMA pour vérifier la progression de la migration :

    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;

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de votre Google Cloud projet.
    • DATASET_NAME : nom de votre ensemble de données.
    • DATASET_REPLICA_STALENESS : configuration d'obsolescence des tables de l'instance répliquée d'ensemble de données que vous avez créée.
    • NEW_REGION : région dans laquelle vous avez créé votre ensemble de données.

  4. Suspendez le flux Datastream existant. Pour en savoir plus, consultez la section Suspendre le flux.

  5. Attendez que le flux soit vidé et notez l'heure à laquelle il est passé à l'état PAUSED.

  6. Vérifiez que les dernières modifications CDC ont été appliquées à la table BigQuery en vérifiant la valeur upsert_stream_apply_watermark de la table. Exécutez la requête suivante et assurez-vous que l'horodatage du filigrane est 10 minutes après la suspension du flux :

    SELECT table_name, upsert_stream_apply_watermark
FROM DATASET_NAME.INFORMATION_SCHEMA.TABLES

    Pour exécuter la requête uniquement pour une table spécifique, ajoutez la clause WHERE suivante :

    WHERE table_name = 'TABLE_NAME'

    Remplacez les éléments suivants :

    • DATASET_NAME : nom de votre ensemble de données.
    • TABLE_NAME : facultatif. Table pour laquelle vous souhaitez vérifier la valeur upsert_stream_apply_watermark.

  7. Utilisez la requête de l'étape 3 pour vérifier que le filigrane de copie de la nouvelle région est postérieur à la valeur upsert_stream_apply_watermark capturée à l'étape 6.

  8. Vous pouvez également comparer manuellement plusieurs tables de l'ensemble de données principal dans la région d'origine avec l'instance répliquée dans la nouvelle région pour vérifier que toutes les données sont correctement copiées.

  9. Promouvez l'instance répliquée d'ensemble de données BigQuery en exécutant la commande suivante dans BigQuery Studio :

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

    Remplacez les éléments suivants :

    • DATASET_NAME : nom de votre ensemble de données.
    • NEW_REGION : région dans laquelle vous avez créé votre ensemble de données.

  10. Si vous n'avez plus besoin de l'ensemble de données d'origine (qui est désormais l'instance répliquée) et que vous ne souhaitez pas générer de frais supplémentaires, accédez à BigQuery Studio et supprimez l'ensemble de données BigQuery d'origine :

    ALTER SCHEMA DATASET_NAME DROP REPLICA IF EXISTS ORIGINAL_REGION;

    Remplacez les éléments suivants :

    • DATASET_NAME : nom de l'ensemble de données d'origine.
    • ORIGINAL_REGION : région de l'ensemble de données d'origine.

  11. Créez un flux avec exactement la même configuration, mais avec un nouvel emplacement de destination BigQuery.

  12. Démarrez le nouveau flux.

    Pour éviter de répliquer des événements en double, démarrez le flux à partir d'une position spécifique :

    • Pour les sources MySQL et Oracle : vous pouvez identifier la position du journal en examinant les journaux du flux d'origine et en recherchant la dernière position à partir de laquelle le flux a été lu avec succès. Pour savoir comment démarrer le flux à partir d'une position spécifique, consultez la section Gérer les flux.
    • Pour les sources PostgreSQL : le nouveau flux commence à lire les modifications à partir du premier numéro de séquence de journal (LSN) dans l'emplacement de réplication. Étant donné que le flux d'origine a peut-être déjà traité certaines de ces modifications, modifiez manuellement le pointeur de l'emplacement de réplication vers le dernier LSN à partir duquel Datastream a effectué la lecture. Vous trouverez ce LSN dans les journaux de consommateur Datastream.

  13. Vous pouvez également supprimer le flux d'origine.