CDC-Tabelle in eine andere Region migrieren

Auf dieser Seite werden Best Practices für einen Anwendungsfall beschrieben, in dem Sie die Datastream-Replikation nach BigQuery eingerichtet, das Zieldataset jedoch in einer falschen Region konfiguriert haben. Anschließend möchten Sie das Dataset in eine andere Region (oder Multi-Region) verschieben, ohne alle Daten aus der Quelldatenbank in BigQuery neu synchronisieren zu müssen.

Wenn Sie während der Migration die sekundäre Region abfragen, werden möglicherweise falsche oder unvollständige Ergebnisse zurückgegeben. Weitere Informationen zu den Einschränkungen im Zusammenhang mit dem auf dieser Seite beschriebenen Migrationsverfahren finden Sie unter Regionsübergreifende Dataset-Replikation.

Hinweis

Bevor Sie Ihre Daten in eine andere Region migrieren, sollten Sie Folgendes beachten:

• Die Migration dauert eine Weile und Sie müssen den Stream während des Vorgangs vorübergehend pausieren. Um die Datenintegrität aufrechtzuerhalten, müssen die Änderungslogs in der Quelldatenbank beibehalten werden, wenn der Stream pausiert wird. Um zu schätzen, wie lange der Stream pausiert werden muss, kombinieren Sie den Wert von max_staleness im Dataset mit dem am längsten laufenden Merge-Vorgang:
  • Informationen dazu, wie lange es dauern kann, bis Zusammenführungen abgeschlossen sind, finden Sie unter Empfohlener Wert für die Tabelle max_staleness.
  • Informationen zum Ermitteln des maximalen max_staleness-Werts im Dataset finden Sie unter Aktuellen max_staleness-Wert einer Tabelle ermitteln. Passen Sie die Abfrage an Ihre spezifischen Anforderungen an.
  • Wenn die geschätzte Pause zu lang ist, als dass sie von Ihrer Quelldatenbank unterstützt werden kann, sollten Sie den Wert von max_staleness für die Tabellen im Dataset vorübergehend verringern.
• Prüfen Sie, ob der Nutzer, der die Migration durchführt, über genügend BigQuery-Ressourcen in der Zielregion verfügt (Abfrage- und Hintergrundreservierung). Weitere Informationen zu Reservierungen finden Sie unter Reservierungszuweisungen.
• Prüfen Sie, ob der Nutzer, der die Migration durchführt, die erforderlichen Berechtigungen für diesen Vorgang hat, z. B. IAM-Berechtigungen (Identity and Access Management) oder VPC Service Controls.

Migrationsschritte

Um die Dataset-Migration zu starten, verwenden Sie die BigQuery-Datenreplikation:

1. Öffnen Sie in der Google Cloud Console die Seite BigQuery Studio.

   Zu BigQuery Studio

2. Erstellen Sie eine BigQuery-Dataset-Replik in der neuen Region:

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

   Ersetzen Sie Folgendes:

   • 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.

3. Beobachten Sie den Migrationsfortschritt und warten Sie, bis das Kopier-Wasserzeichen auf dem Replikat nur noch wenige Minuten vom primären Wasserzeichen entfernt ist. Sie können diese Abfrage in der BigQuery INFORMATION_SCHEMA ausführen, um den Migrationsfortschritt zu prüfen:

   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;
   

   Ersetzen Sie Folgendes:

   • PROJECT_ID: Die ID Ihres Projekts in Google Cloud .
   • DATASET_NAME: der Name Ihres Datasets.
   • DATASET_REPLICA_STALENESS: die Konfiguration der Aktualität der Tabellen im von Ihnen erstellten Dataset-Replikat.
   • NEW_REGION: die Region, in der Sie Ihr Dataset erstellt haben.

4. Pausieren Sie den vorhandenen Datastream. Weitere Informationen finden Sie unter Stream pausieren.

5. Warten Sie, bis der Stream beendet ist, und notieren Sie sich, wann der Stream den Status PAUSED erreicht hat.

6. Prüfen Sie anhand der upsert_stream_apply_watermark für die Tabelle, ob die neuesten CDC-Änderungen auf die BigQuery-Tabelle angewendet wurden. Führen Sie die folgende Abfrage aus und prüfen Sie, ob der Zeitstempel des Wasserzeichens 10 Minuten nach dem Pausieren des Streams liegt:

   SELECT table_name, upsert_stream_apply_watermark
   FROM DATASET_NAME.INFORMATION_SCHEMA.TABLES
   

   Wenn Sie die Abfrage nur für eine bestimmte Tabelle ausführen möchten, fügen Sie die folgende WHERE-Klausel hinzu:

   WHERE table_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.

7. Verwenden Sie die Abfrage aus Schritt 3, um zu prüfen, ob das neue Wasserzeichen für die Regionskopie später als das in Schritt 6 erfasste upsert_stream_apply_watermark ist.

8. 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 zu prüfen, ob alle Daten korrekt kopiert wurden.

9. Stufen Sie die BigQuery-Dataset-Replik hoch, indem Sie den folgenden Befehl in BigQuery Studio ausführen:

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

   Ersetzen Sie Folgendes:

   • DATASET_NAME: der Name Ihres Datasets.
   • NEW_REGION: die Region, in der Sie Ihr Dataset erstellt haben.

10. Wenn Sie das ursprüngliche Dataset (jetzt das Replikat) nicht mehr benötigen und keine zusätzlichen Gebühren anfallen sollen, können Sie es in BigQuery Studio löschen:

    ALTER SCHEMA DATASET_NAME DROP REPLICA IF EXISTS ORIGINAL_REGION;
    

    Ersetzen Sie Folgendes:

    • DATASET_NAME: der Name des ursprünglichen Datasets.
    • ORIGINAL_REGION: die Region des ursprünglichen Datasets.

11. Erstellen Sie einen neuen Stream mit genau derselben Konfiguration, aber mit einem neuen BigQuery-Zielstandort.

12. Starte den neuen Stream.

    Um die Replikation doppelter Ereignisse zu verhindern, können Sie den Stream an einer bestimmten Position starten:

    • Bei MySQL- und Oracle-Quellen können Sie die Logposition ermitteln, indem Sie die Logs des ursprünglichen Streams untersuchen und die letzte Position suchen, ab der der Stream erfolgreich gelesen wurde. Informationen zum Starten des Streams an einer bestimmten Position finden Sie unter Streams verwalten.
    • Bei PostgreSQL-Quellen: Der neue Stream beginnt mit dem Lesen von Änderungen ab der ersten Logsequenznummer (LSN) im Replikationsslot. Da im ursprünglichen Stream einige dieser Änderungen möglicherweise bereits verarbeitet wurden, müssen Sie den Zeiger des Replikationsslots manuell auf die letzte LSN ändern, aus der Datastream gelesen hat. Sie finden diese LSN in den Logs des Datastream-Consumers.

13. Löschen Sie optional den ursprünglichen Stream.