Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Auf dieser Seite werden Best Practices für einen Anwendungsfall beschrieben, in dem Sie die Datastream-Replikation nach BigQuery eingerichtet, aber den Zieldatensatz in einer falschen Region konfiguriert haben. Sie möchten das Dataset dann in eine andere Region (oder mehrere Regionen) verschieben, ohne alle Daten aus der Quelldatenbank noch einmal mit BigQuery zu synchronisieren.
Hinweise
Beachten Sie die folgenden Punkte, bevor Sie mit der Migration Ihrer Daten in eine andere Region beginnen:
Die Migration dauert einige Zeit und Sie müssen den Stream während des Vorgangs vorübergehend pausieren. Um die Datenintegrität zu wahren, müssen die Änderungsprotokolle in der Quelldatenbank beibehalten werden, wenn der Stream pausiert wird. Um abzuschätzen, wie lange der Stream pausiert werden soll, kombinieren Sie den Wert von max_staleness im Datensatz mit dem längsten Zusammenführungsvorgang:
Wenn die geschätzte Pause zu lang ist, um von Ihrer Quelldatenbank unterstützt zu werden, können Sie den Wert von max_staleness für die Tabellen im Datensatz vorübergehend reduzieren.
Prüfen Sie, ob der Nutzer, der die Migration durchführt, über ausreichende BigQuery-Ressourcen in der Zielregion verfügt (Abfragereservierung und Hintergrundreservierung). Weitere Informationen zu Reservierungen finden Sie unter Reservierungszuweisungen.
DATASET_NAME: Der Name des Datasets, das Sie erstellen möchten.
NEW_REGION: der Name der Region, in der Sie das Dataset erstellen möchten. Beispiel: region-us.
Beobachten Sie den Migrationsfortschritt und warten Sie, bis das Kopierwasserzeichen im Replikat nur noch wenige Minuten vom primären Datenträger entfernt ist. Sie können diese Abfrage im BigQuery INFORMATION_SCHEMA ausführen, um den Migrationsfortschritt zu prüfen:
DATASET_REPLICA_STALENESS: die Staleness-Konfiguration der Tabellen im von Ihnen erstellten Dataset-Replikat.
NEW_REGION: die Region, in der Sie das Dataset erstellt haben.
Pausieren Sie den vorhandenen Datastream-Stream. Weitere Informationen finden Sie unter Stream pausieren.
Warten Sie, bis der Stream vollständig abgelaufen ist, und notieren Sie sich die Zeit, zu der der Stream den Status PAUSED erreicht hat.
Prüfen Sie, ob die neuesten CDC-Änderungen auf die BigQuery-Tabelle angewendet wurden. Sehen Sie dazu in der Tabelle nach, ob das Symbol upsert_stream_apply_watermark angezeigt wird. Führe die folgende Abfrage aus und achte darauf, dass der Zeitstempel des Wasserzeichens 10 Minuten nach dem Pausieren des Streams liegt:
Wenn Sie die Abfrage nur für eine bestimmte Tabelle ausführen möchten, fügen Sie die folgende WHERE-Klausel hinzu:
WHEREtable_name='TABLE_NAME'
Ersetzen Sie Folgendes:
DATASET_NAME: der Name Ihres Datasets.
TABLE_NAME: Optional. Die Tabelle, für die Sie die upsert_stream_apply_watermark prüfen möchten.
Verwende die Abfrage aus Schritt 3, um zu prüfen, ob das Wasserzeichen der Kopie der neuen Region später als die in Schritt 6 erfasste upsert_stream_apply_watermark ist.
Optional können Sie mehrere Tabellen im primären Dataset in der ursprünglichen Region manuell mit dem Replikat in der neuen Region vergleichen, um sicherzustellen, dass alle Daten korrekt kopiert wurden.
Führen Sie in BigQuery Studio den folgenden Befehl aus, um das BigQuery-Dataset-Replikat zu befördern:
NEW_REGION: die Region, in der Sie das Dataset erstellt haben.
Wenn Sie das ursprüngliche Dataset (jetzt das Replikat) nicht mehr benötigen und keine zusätzlichen Kosten verursachen möchten, können Sie es in BigQuery Studio löschen:
ORIGINAL_REGION: die Region des ursprünglichen Datasets.
Erstellen Sie einen neuen Stream mit genau derselben Konfiguration, aber mit einem neuen BigQuery-Zielspeicherort.
Starte den neuen Stream.
Um zu verhindern, dass doppelte Ereignisse repliziert werden, starten Sie den Stream an einer bestimmten Position:
Bei MySQL- und Oracle-Quellen: Sie können die Protokollposition ermitteln, indem Sie die Protokolle des ursprünglichen Streams prüfen und die letzte Position ermitteln, von der aus der Stream erfolgreich gelesen wurde. Informationen zum Starten des Streams an einer bestimmten Position findest du unter Streams verwalten.
Bei PostgreSQL-Quellen: Der neue Stream beginnt mit dem Lesen von Änderungen ab der ersten Logsequenznummer (LSN) im Replikationsslot. Da einige dieser Änderungen möglicherweise bereits im ursprünglichen Stream verarbeitet wurden, ändern Sie den Zeiger des Replikationsslots manuell auf die letzte LSN, aus der Datastream gelesen hat.
Diese LSN findest du in den Datastream-Nutzerprotokollen.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[[["\u003cp\u003eThis guide details how to migrate a BigQuery dataset to a new region without a full data re-synchronization when using Datastream replication.\u003c/p\u003e\n"],["\u003cp\u003eThe migration process involves creating a dataset replica in the new region, temporarily pausing the Datastream stream, and monitoring the data transfer progress.\u003c/p\u003e\n"],["\u003cp\u003eBefore initiating the migration, you must estimate the required stream pause duration based on the dataset's \u003ccode\u003emax_staleness\u003c/code\u003e and the merge operation time, while ensuring the source database retains change logs.\u003c/p\u003e\n"],["\u003cp\u003eOnce the replica's data is consistent and the stream is paused, the replica is promoted to the primary dataset and a new stream is created with the correct BigQuery destination.\u003c/p\u003e\n"],["\u003cp\u003eUsers should also ensure sufficient BigQuery resources and permissions are available in the destination region before commencing the dataset migration.\u003c/p\u003e\n"]]],[],null,["# Migrate a CDC table to another region\n\nThis page describes best practices for a use case where you've set up\nDatastream replication to BigQuery but configured the\ndestination dataset in an incorrect region. You then want to move the dataset to\nanother region (or multi-region) without having to re-synchronise all of the data\nfrom the source database to BigQuery.\n\n\u003cbr /\u003e\n\n| Querying the secondary region during the migration procedure might return incorrect or incomplete results. For more information about the limitations related to the migration procedure described on this page, see [Cross-region dataset replication](/bigquery/docs/data-replication#limitations).\n\n\u003cbr /\u003e\n\nBefore you begin\n----------------\n\nBefore you start migrating your data to another region, consider the\nfollowing:\n\n- Migration takes time, and you must temporarily pause the stream during the operation. To maintain data integrity, the source database must retain the change logs when the stream is paused. To estimate how long to pause the stream, combine the value of `max_staleness` in the dataset and the longest-running merge operation:\n - For information about how long it might take for merge operations to finish, see [Recommended table `max_staleness` value](/bigquery/docs/change-data-capture#recommended-max-staleness).\n - To find the maximum `max_staleness` in the dataset, see [Determine the current `max_staleness` value of a table](/bigquery/docs/change-data-capture#determine-max-staleness) and adjust the query to your specific needs.\n - If the estimated pause is too long for your source database to support, you might want to consider temporarily reducing the value of `max_staleness` for the tables in the dataset.\n- Verify that the user performing the migration has sufficient BigQuery resources in the destination region (query reservation and background reservation). For more information about reservations, see [Reservation assignments](/bigquery/docs/reservations-intro#assignments).\n- Verify that the user performing the migration has sufficient permissions to perform this operation, such as [Identity and Access Management (IAM)](/iam) controls or [VPC Service Controls](/security/vpc-service-controls).\n\nMigration steps\n---------------\n\nTo initiate [dataset migration](/bigquery/docs/data-replication#migrate_datasets),\nuse BigQuery data replication:\n\n1. In the Google Cloud console, go to the **BigQuery Studio** page.\n\n [Go to BigQuery Studio](https://console.cloud.google.com/bigquery)\n2. Create a BigQuery dataset replica in the new region:\n\n ALTER SCHEMA \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-n\"\u003eDATASET_NAME\u003c/span\u003e\u003c/var\u003e\n ADD REPLICA '\u003cvar translate=\"no\"\u003eNEW_REGION\u003c/var\u003e'\n OPTIONS(location='\u003cvar translate=\"no\"\u003eNEW_REGION\u003c/var\u003e');\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eDATASET_NAME\u003c/var\u003e: the name of the dataset that you want to create.\n - \u003cvar translate=\"no\"\u003eNEW_REGION\u003c/var\u003e: the name of the region where you want to create your dataset. For example, `region-us`.\n3. Monitor the migration progress, and wait until the copy watermark in the\n replica is within a few minutes of the primary. You can run this query on\n the [BigQuery INFORMATION_SCHEMA](/bigquery/docs/information-schema-schemata-replicas#schema)\n to check the migration progress:\n\n SELECT\n catalog_name as project_id,\n schema_name as dataset_name,\n replication_time as dataset_replica_staleness\n FROM\n '\u003cvar translate=\"no\"\u003eNEW_REGION\u003c/var\u003e'.INFORMATION_SCHEMA.SCHEMATA_REPLICAS\n WHERE\n catalog_name = \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-n\"\u003ePROJECT_ID\u003c/span\u003e\u003c/var\u003e\n AND schema_name = \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-n\"\u003eDATASET_NAME\u003c/span\u003e\u003c/var\u003e\n AND location = \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-n\"\u003eNEW_REGION\u003c/span\u003e\u003c/var\u003e;\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e: the ID of your Google Cloud project.\n - \u003cvar translate=\"no\"\u003eDATASET_NAME\u003c/var\u003e: the name of your dataset.\n - \u003cvar translate=\"no\"\u003eDATASET_REPLICA_STALENESS\u003c/var\u003e: the staleness configuration of the tables in the dataset replica that you created.\n - \u003cvar translate=\"no\"\u003eNEW_REGION\u003c/var\u003e: the region where you created your dataset.\n4. Pause the existing Datastream stream. For more information, see\n [Pause the stream](/datastream/docs/run-a-stream#pauseastream).\n\n5. Wait for the stream to drain and take note of the time when the stream entered the\n `PAUSED` state.\n\n6. Confirm that the latest CDC changes have been applied to the BigQuery\n table by checking the [`upsert_stream_apply_watermark`](/bigquery/docs/change-data-capture#monitor_table_upsert_operation_progress)\n for the table. Run the following query and ensure that the watermark timestamp\n is 10 minutes later then when the stream was paused:\n\n SELECT table_name, upsert_stream_apply_watermark\n FROM \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-n\"\u003eDATASET_NAME\u003c/span\u003e\u003c/var\u003e.INFORMATION_SCHEMA.TABLES\n\n To run the query only for a specific table, add the following `WHERE` clause: \n\n WHERE table_name = '\u003cvar translate=\"no\"\u003eTABLE_NAME\u003c/var\u003e'\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eDATASET_NAME\u003c/var\u003e: the name of your dataset.\n - \u003cvar translate=\"no\"\u003eTABLE_NAME\u003c/var\u003e: optional. The table for which you want to check the `upsert_stream_apply_watermark`.\n7. Use the query from step 3 to verify that the new region copy watermark is\n later than the `upsert_stream_apply_watermark` captured in step 6.\n\n8. Optionally, manually compare several tables in the primary dataset in the\n original region with the replica in the new region to verify that all data\n is correctly copied.\n\n9. Promote the BigQuery dataset replica by running the following\n command in BigQuery Studio:\n\n ALTER SCHEMA \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-n\"\u003eDATASET_NAME\u003c/span\u003e\u003c/var\u003e\n SET OPTIONS(primary_replica = '\u003cvar translate=\"no\"\u003eNEW_REGION\u003c/var\u003e');\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eDATASET_NAME\u003c/var\u003e: the name of your dataset.\n - \u003cvar translate=\"no\"\u003eNEW_REGION\u003c/var\u003e: the region where you created your dataset.\n10. Optionally, if you no longer need the original dataset (now the replica), and\n don't want to incur extra charges, then go to BigQuery Studio and drop\n the original BigQuery dataset:\n\n ALTER SCHEMA \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-n\"\u003eDATASET_NAME\u003c/span\u003e\u003c/var\u003e DROP REPLICA IF EXISTS \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-n\"\u003eORIGINAL_REGION\u003c/span\u003e\u003c/var\u003e;\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eDATASET_NAME\u003c/var\u003e: the name of the original dataset.\n - \u003cvar translate=\"no\"\u003eORIGINAL_REGION\u003c/var\u003e: the region of the original dataset.\n11. Create a new stream with the exact same configuration but with new BigQuery\n destination location.\n\n12. Start the new stream.\n\n To prevent replicating duplicate events, start\n the stream from a specific position:\n - For MySQL and Oracle sources: you can identify the log position by examining the logs of the original stream and finding the last position from which the stream read successfully. For information about starting the stream from a specific position, see [Manage streams](/datastream/docs/manage-streams#startastreamfromspecific).\n - For PostgreSQL sources: the new stream starts reading changes from the first log sequence number (LSN) in the replication slot. Because the original stream might have already processed some of these changes, manually change the pointer of the replication slot to the last LSN from which Datastream read. You can find this LSN in the Datastream consumer logs.\n13. Optionally, delete the original stream."]]