Regionenübergreifende Dataset-Replikation

Vorschau

Dieses Produkt oder diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Funktionen sind unverändert verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Mit der BigQuery-Dataset-Replikation können Sie die automatische Replikation eines Datasets zwischen zwei verschiedenen Regionen oder Multi-Regionen einrichten.

Überblick

Beim Erstellen eines Datasets in BigQuery wählen Sie die Region oder Multi-Region aus, in der die Daten gespeichert werden. Eine Region ist eine Sammlung von Rechenzentren innerhalb eines geografischen Bereichs. Eine Multiregion ist ein großes geografisches Gebiet, das zwei oder mehr geografische Regionen enthält. Die Daten werden in einer der enthaltenen Regionen gespeichert.

BigQuery speichert immer Kopien Ihrer Daten in zwei verschiedenen Google Cloud-Zonen am Dataset-Standort. Eine Zone ist ein Bereich, in dem Google Cloud-Ressourcen innerhalb einer Region bereitgestellt werden. In allen Regionen verwendet die Replikation zwischen Zonen synchrone zweifache Exporte. Die Auswahl eines multiregionalen Standorts bietet keine regionsübergreifende Replikation oder regionale Redundanz, sodass die Verfügbarkeit der Datasets im Falle eines regionalen Ausfalls nicht erhöht wird. Die Daten werden in einer einzelnen Region innerhalb des geografischen Standorts gespeichert.

Für zusätzliche Georedundanz können Sie jedes Dataset replizieren. BigQuery erstellt ein sekundäres Replikat des Datasets in einer von Ihnen angegebenen Region. Dieses Replikat wird dann asynchron zwischen zwei Zonen mit der anderen Region repliziert, also insgesamt vier zonale Kopien.

Dataset-Replikation

Wenn Sie ein Dataset replizieren, speichert BigQuery die Daten in der von Ihnen angegebenen Region.

• Primäre Region. Wenn Sie ein Dataset erstellen, wird das Dataset in BigQuery in der primären Region platziert.

• Sekundäre Region. Wenn Sie ein Dataset-Replikat hinzufügen, wird das Replikat von BigQuery in der sekundären Region platziert.

Anfänglich ist das Replikat in der primären Region das primäre Replikat und das Replikat in der sekundären Region das sekundäre Replikat.

Das primäre Replikat ist beschreibbar und das sekundäre Replikat ist schreibgeschützt. Schreibvorgänge auf dem primären Replikat werden asynchron auf das sekundäre Replikat repliziert. Innerhalb jeder Region werden die Daten redundant in zwei Zonen gespeichert. Netzwerktraffic verlässt niemals das Google Cloud-Netzwerk.

Im folgenden Diagramm wird die Replikation gezeigt, die bei der Replikation eines Datasets auftritt:

Wenn die primäre Region online ist, können Sie manuell zum sekundären Replikat wechseln. Weitere Informationen finden Sie unter Sekundäres Replikat hochstufen.

Preise

Folgende Replikate werden Ihnen in Rechnung gestellt:

• Storage. Speicherbyte in der sekundären Region werden als separate Kopie in der sekundären Region abgerechnet. Siehe BigQuery-Speicherpreise.
• Datenreplikation. Weitere Informationen zu den Preisen für die Datenreplikation finden Sie unter Preise für die Datenreplikation.

Rechenkapazität in der sekundären Region

Zur Ausführung von Jobs und Abfragen für das Replikat in der sekundären Region müssen Sie Slots in der sekundären Region erwerben oder eine On-Demand-Abfrage ausführen.

Sie können die Slots verwenden, um schreibgeschützte Abfragen aus dem sekundären Replikat auszuführen. Wenn Sie das sekundäre Replikat zum primären Replikat hochstufen, können Sie diese Slots auch zum Schreiben in das Replikat verwenden.

Sie können die gleiche Anzahl von Slots wie in der primären Region oder eine andere Anzahl an Slots erwerben. Wenn Sie weniger Slots erwerben, kann sich dies auf die Abfrageleistung auswirken.

Überlegungen zum Standort

Bevor Sie ein Dataset-Replikat hinzufügen, müssen Sie das erste Dataset erstellen, das Sie in BigQuery replizieren möchten, sofern noch keines vorhanden ist. Als Speicherort des hinzugefügten Replikats wird der Standort festgelegt, den Sie beim Hinzufügen des Replikats angeben. Der Speicherort des hinzugefügten Replikats muss sich vom Standort des anfänglichen Datasets unterscheiden. Dies bedeutet, dass die Daten in Ihrem Dataset kontinuierlich zwischen dem Standort, an dem das Dataset erstellt wurde, und dem Standort des Replikats repliziert werden. Für Replikate, die am selben Standort gespeichert sein müssen, z. B. Ansichten, materialisierte Ansichten oder externe Nicht-BigLake-Tabellen, fügen Sie ein Replikat an einem Speicherort hinzu, der sich von Ihrer Quelle unterscheidet oder mit dieser nicht kompatibel ist. Der Standort der Daten kann dann zu Jobfehlern führen.

Wenn Kunden ein Dataset regionenübergreifend replizieren, sorgt BigQuery dafür, dass sich Daten nur an den Standorten befinden, an denen die Replikate erstellt wurden.

Colocations-Anforderungen

Die Verwendung der Dataset-Replikation hängt von den folgenden Colocations-Anforderungen ab.

Cloud Storage

Zum Abfragen von Daten in Cloud Storage muss sich der Cloud Storage-Bucket am Replikat befinden. Berücksichtigen Sie bei der Wahl des Speicherorts des Replikats die Überlegungen zum externen Tabellenstandort.

Beschränkungen

Die BigQuery-Dataset-Replikation unterliegt den folgenden Einschränkungen:

• Daten in Streams, die nicht mit Commit gespeichert wurden, werden im sekundären Replikat nicht repliziert, wenn die Tabelle mit der BigQuery Storage Write API geschrieben wird. Die Replikation von Streamingdaten über die BigQuery Storage Write API oder tabledata.insertAll erfolgt auf Best-Effort-Basis und kann zu einer hohen Replikationsverzögerung führen.
• Die BigQuery Storage Read API unterstützt kein Lesen aus Tabellen, die im sekundären Dataset-Replikat enthalten sind. Zum Lesen aus einer Tabelle, die im sekundären Replikat enthalten ist, muss das sekundäre Replikat zuerst zum primären Replikat hochgestuft werden.
• Tabellen, die mithilfe von Change Data Capture über Datastream in BigQuery eingefügt werden, werden nicht unterstützt.
• Replikation und Switchover werden über DDL-Anweisungen (Data Definition Language, Datendefinitionssprache) verwaltet.
• Sie sind auf jeweils ein Replikat jedes Datasets pro Region oder Multi-Region beschränkt. Sie können nicht zwei sekundäre Replikate desselben Datasets in derselben Zielregion erstellen.
• Ressourcen innerhalb von Replikaten unterliegen den unter Ressourcenverhalten beschriebenen Einschränkungen.
• Richtlinien-Tags und zugehörige Datenrichtlinien werden nicht in das sekundäre Replikat repliziert. Alle Abfragen, die auf Spalten mit Richtlinien-Tags in anderen Regionen als der ursprünglichen Region verweisen, schlagen fehl, auch wenn das Replikat hochgestuft wird.
• Zeitreisen sind nur im sekundären Replikat verfügbar, nachdem das sekundäre Replikat erstellt wurde.
• Sie können ein Dataset nur mit weniger als 100.000 Tabellen replizieren.
• Es können maximal vier Replikate pro Dataset und Tag für dieselbe Region hinzugefügt (und dann gelöscht) werden.
• Die Replikationsbandbreite für den ersten Kopiervorgang ist auf 1 physisches GB/Sekunde pro Projekt und Kontinentpaar beschränkt. Die Replikation mit dieser Geschwindigkeit ist nicht garantiert.
• Tabellen mit vom Kunden verwalteten Verschlüsselungsschlüsseln (CMEK) können in der sekundären Region nicht abgefragt werden, wenn der replica_kms_key-Wert nicht konfiguriert ist.
• BigLake-Tabellen werden nicht unterstützt.

Ressourcenverhalten

Die folgenden Vorgänge werden für Ressourcen innerhalb des sekundären Replikats nicht unterstützt:

• Tabelle klonen
• Tabellen-Snapshot erstellen

Wenn Sie eine Kopie einer Ressource in einem sekundären Replikat erstellen müssen, müssen Sie die Ressource kopieren oder abfragen und dann die Ergebnisse außerhalb des sekundären Replikats erfassen. Verwenden Sie beispielsweise CREATE TABLE AS SELECT, um eine neue Ressource aus der sekundären Replikatressource zu erstellen.

Primäre und sekundäre Replikate unterliegen den folgenden Unterschieden:

Primäres Replikat aus Region 1	Sekundäres Replikat aus Region 2	Hinweise
BigLake-Tabelle	BigLake-Tabelle	Nicht unterstützt.
Externe Tabelle	Externe Tabelle	Nur die Definition der externen Tabelle wird repliziert. Die Abfrage schlägt fehl, wenn sich der Cloud Storage-Bucket nicht am selben Standort wie ein Replikat befindet.
Logische Ansicht	Logische Ansicht	Logische Ansichten, die auf ein Dataset oder eine Ressource verweisen, die sich nicht am selben Standort wie die logische Ansicht befinden, schlagen bei der Abfrage fehl.
Verwaltete Tabelle	Verwaltete Tabelle	Kein Unterschied
Materialisierte Ansicht	Materialisierte Ansicht	Wenn sich eine referenzierte Tabelle nicht in derselben Region wie die materialisierte Ansicht befindet, schlägt die Abfrage fehl. Replizierte materialisierte Ansichten können über der maximalen Veralterung der Ansicht liegen.
Modell	Modell	Als verwaltete Tabellen gespeichert.
Remote-Funktion	Remote-Funktion	Verbindungen sind regional. Remote-Funktionen, die auf ein Dataset oder eine Ressource (Verbindung) verweisen, die sich nicht am selben Standort wie die Remote-Funktion befinden, schlagen bei der Ausführung fehl.
Routinen	Benutzerdefinierte Funktion (UDF) oder gespeicherte Prozedur	Abläufe, die auf ein Dataset oder eine Ressource verweisen, die sich nicht am selben Standort wie die Routine befinden, schlagen bei der Ausführung fehl. Routinen, die auf eine Verbindung verweisen, z. B. Remote-Funktionen, funktionieren nicht außerhalb der Quellregion.
Zeilenzugriffsrichtlinie	Zeilenzugriffsrichtlinie	Kein Unterschied
Google-Suchindex	Google-Suchindex	Nicht repliziert.
Gespeicherte Prozedur	Gespeicherte Prozedur	Gespeicherte Prozeduren, die auf ein Dataset oder eine Ressource verweisen, die sich nicht am selben Standort wie die gespeicherte Prozedur befinden, schlagen bei der Ausführung fehl.
Tabellenklon	Verwaltete Tabelle	Wird als tiefe Kopie im sekundären Replikat abgerechnet.
Tabellen-Snapshot	Tabellen-Snapshot	Wird als tiefe Kopie im sekundären Replikat abgerechnet.
Tabellenwertfunktion (Table-valued function, TVF)	TVF	TVFs, die auf ein Dataset oder eine Ressource verweisen, die sich nicht am selben Standort wie die TVF befinden, schlagen bei der Ausführung fehl.
UDF	UDF	UDFs, die auf ein Dataset oder eine Ressource verweisen, die sich nicht am selben Standort wie die UDF befinden, schlagen bei der Ausführung fehl.

Ausfallszenarien

Die regionenübergreifende Replikation ist nicht für den Notfallwiederherstellungsplan während eines Ausfalls der gesamten Region vorgesehen. Bei einem Ausfall der gesamten Region in der Region des primären Replikats können Sie das sekundäre Replikat nicht hochstufen. Da sekundäre Replikate schreibgeschützt sind, können Sie keine Schreibvorgänge auf dem sekundären Replikat ausführen und die sekundäre Region erst hochstufen, wenn die Region des primären Replikats wiederhergestellt wurde.

In der folgenden Tabelle werden die Auswirkungen von Ausfällen der gesamten Region auf Ihre replizierten Daten erläutert:

Region 1	Region 2	Ausfallregion	Auswirkungen
Primäres Replikat	Sekundäres Replikat	Region 2	Schreibgeschützte Jobs, die in Region 2 ausgeführt werden, schlagen fehl.
Primäres Replikat	Sekundäres Replikat	Region 1	Alle in Region 1 ausgeführten Jobs schlagen fehl. Schreibgeschützte Jobs werden weiterhin in Region 2 ausgeführt, in der sich das sekundäre Replikat befindet. Der Inhalt von Region 2 ist veraltet, bis er erfolgreich mit Region 1 synchronisiert wird.

Dataset-Replikation verwenden

In diesem Abschnitt wird beschrieben, wie Sie ein Dataset replizieren, das sekundäre Replikat hochstufen und BigQuery-Lesejobs in der sekundären Region ausführen.

Erforderliche Berechtigungen

Bitten Sie Ihren Administrator, Ihnen die Berechtigung bigquery.datasets.update zu erteilen, um die Berechtigungen zu erhalten, die Sie zum Verwalten von Replikaten benötigen.

Dataset replizieren

Zum Replizieren eines Datasets verwenden Sie die ALTER SCHEMA ADD REPLICA-DDL-Anweisung.

Sie können ein Replikat zu jedem Dataset hinzufügen, das sich in einer Region oder Multi-Region befindet und noch nicht in dieser Region oder Multi-Region repliziert wurde. Nachdem Sie ein Replikat hinzugefügt haben, dauert es einige Zeit, bis der erste Kopiervorgang abgeschlossen ist. Sie können weiterhin Abfragen ausführen, die auf das primäre Replikat verweisen, während die Daten repliziert werden, ohne die Abfrageverarbeitungskapazität zu reduzieren. Sie können Daten an den geografischen Standorten innerhalb einer Multi-Region nicht replizieren.

Im folgenden Beispiel wird ein Dataset mit dem Namen my_dataset am multiregionalen Standort US erstellt und dann ein Replikat mit dem Namen us-east4 hinzugefügt:

-- Create the primary replica in the US multi-region.
CREATE SCHEMA my_dataset OPTIONS(location='us');

-- Create a replica in the secondary region.
ALTER SCHEMA my_dataset
ADD REPLICA `us-east4`
OPTIONS(location='us-east4');

Wenn Sie wissen möchten, wann das sekundäre Replikat erfolgreich erstellt wurde, können Sie die Spalte creation_complete in der Ansicht INFORMATION_SCHEMA.SCHEMATA_REPLICAS abfragen.

Sekundäres Replikat hochstufen

Wenn die primäre Region online ist, können Sie das sekundäre Replikat hochstufen. Eine „Hochstufung“ macht das sekundäre Replikat zur beschreibbaren primären Instanz. Dieser Vorgang ist innerhalb weniger Sekunden abgeschlossen, wenn das sekundäre Replikat auf dem primären Replikat aktuell ist. Wenn das sekundäre Replikat nicht auf dem neuesten Stand ist, kann die Hochstufung erst abgeschlossen werden, wenn es aktuell ist. Das sekundäre Replikat kann nicht zum primären Replikat hochgestuft werden, wenn die Region mit der primären Instanz ausfällt.

Bitte beachten Sie dabei Folgendes:

• Alle Schreibvorgänge in Tabellen geben Fehler zurück, während die Hochstufung ausgeführt wird. Das alte primäre Replikat kann sofort zu Beginn nicht mehr geschrieben werden.
• Tabellen, die zum Zeitpunkt des Hochstufens nicht vollständig repliziert werden, geben veraltete Lesevorgänge zurück.

Verwenden Sie die DDL-Anweisung ALTER SCHEMA SET OPTIONS und legen Sie die Option primary_replica fest, um ein Replikat zu einem primären Replikat hochzustufen.

Beachten Sie Folgendes: Sie müssen den Jobstandort in den Abfrageeinstellungen explizit auf die sekundäre Region festlegen. Siehe BigQuery-Standorte angeben.

Im folgenden Beispiel wird das Replikat us-east4 zum primären Replikat hochgestuft:

ALTER SCHEMA my_dataset SET OPTIONS(primary_replica = 'us-east4')

Wenn Sie wissen möchten, wann das sekundäre Replikat erfolgreich hochgestuft wurde, können Sie in der Ansicht INFORMATION_SCHEMA.SCHEMATA_REPLICAS die Spalte replica_primary_assignment_complete abfragen.

Dataset-Replikat entfernen

Wenn Sie ein Replikat entfernen und das Dataset nicht mehr replizieren möchten, verwenden Sie die DDL-Anweisung ALTER SCHEMA DROP REPLICA.

Im folgenden Beispiel wird das Replikat us entfernt:

ALTER SCHEMA my_dataset
DROP REPLICA IF EXISTS `us`;

Sie müssen zuerst alle sekundären Replikate löschen, um das gesamte Dataset zu löschen. Wenn Sie das gesamte Dataset löschen, z. B. mit der Anweisung DROP SCHEMA, ohne alle sekundären Replikate zu löschen, erhalten Sie eine Fehlermeldung.

Dataset-Replikate auflisten

Fragen Sie die Ansicht INFORMATION_SCHEMA.SCHEMATA_REPLICAS ab, um die Dataset-Replikate in einem Projekt aufzulisten.

Datasets migrieren

Sie können die regionenübergreifende Dataset-Replikation verwenden, um Ihre Datasets von einer Region in eine andere zu migrieren. Das folgende Beispiel zeigt den Prozess der Migration des vorhandenen Datasets my_migration von der Multi-Region US mithilfe der regionenübergreifenden Replikation auf die Multi-Region EU.

Dataset replizieren

Zum Starten des Migrationsprozesses replizieren Sie zuerst das Dataset in der Region, in die Sie die Daten migrieren möchten. In diesem Szenario migrieren Sie das Dataset my_migration zur Multi-Region EU.

-- Create a replica in the secondary region.
ALTER SCHEMA my_migration
ADD REPLICA `eu`
OPTIONS(location='eu');

Dadurch wird ein sekundäres Replikat mit dem Namen eu am multiregionalen Standort EU erstellt. Das primäre Replikat ist das Dataset my_migration am multiregionalen Standort US.

Sekundäres Replikat hochstufen

Wenn Sie das Dataset weiterhin in die Multi-Region EU migrieren möchten, stufen Sie das sekundäre Replikat hoch:

ALTER SCHEMA my_migration SET OPTIONS(primary_replica = 'eu')

Nach Abschluss der Hochstufung ist eu das primäre Replikat. Es ist ein beschreibbares Replikat.

Migration abschließen

Um die Migration von der US-Multi-Region zur EU-Multi-Region abzuschließen, löschen Sie das us-Replikat. Dieser Schritt ist nicht erforderlich, aber nützlich, wenn Sie kein Dataset-Replikat benötigen, das über Ihre Migrationsanforderungen hinausgeht.

ALTER SCHEMA my_migration
DROP REPLICA IF EXISTS us;

Ihr Dataset befindet sich in der EU-Multi-Region und es gibt keine Replikate des my_migration-Datasets. Sie haben Ihr Dataset erfolgreich in die Multi-Region EU migriert. Die vollständige Liste der migrierten Ressourcen finden Sie unter Ressourcenverhalten.

Kunden-verwaltete Verschlüsselungsschlüssel (CMEK)

Vom Kunden verwaltete Cloud Key Management Service-Schlüssel werden beim Erstellen eines sekundären Replikats nicht automatisch repliziert. Sie müssen replica_kms_key für den Speicherort des hinzugefügten Replikats festlegen, um die Verschlüsselung für das replizierte Dataset beizubehalten. Sie können replica_kms_key mit der DDL-Anweisung ALTER SCHEMA ADD REPLICA festlegen.

Das Replizieren von Datasets mit CMEK verhält sich wie in den folgenden Szenarien beschrieben:

• Wenn das Quell-Dataset ein default_kms_key hat, müssen Sie replica_kms_key angeben, das in der Region des Replikat-Datasets erstellt wurde, wenn die DDL-Anweisung ALTER SCHEMA ADD REPLICA verwendet wird.

• Wenn im Quell-Dataset kein Wert für default_kms_key festgelegt ist, können Sie replica_kms_key nicht festlegen.

• Wenn Sie die Cloud KMS-Schlüsselrotation für default_kms_key oder replica_kms_key verwenden, kann das replizierte Dataset nach der Schlüsselrotation weiterhin abgefragt werden.

  • Die Schlüsselrotation in der primären Region aktualisiert die Schlüsselversion nur in Tabellen, die nach der Rotation erstellt wurden. Tabellen, die vor der Schlüsselrotation vorhanden waren, verwenden weiterhin die Schlüsselversion, die vor der Rotation festgelegt wurde.
  • Die Schlüsselrotation in der sekundären Region aktualisiert alle Tabellen im sekundären Replikat auf die neue Schlüsselversion.
  • Wenn Sie das primäre Replikat auf das sekundäre Replikat umstellen, werden alle Tabellen im sekundären Replikat (früher das primäre Replikat) auf die neue Schlüsselversion aktualisiert.
  • Wenn die Schlüsselversion, die für Tabellen im primären Replikat vor der Schlüsselrotation festgelegt wurde, wird gelöscht, können Tabellen, die noch die Schlüsselversion verwenden, die vor der Schlüsselrotation festgelegt wurde, erst abgefragt werden, wenn die Schlüsselversion aktualisiert wurde. Damit die Schlüsselversion aktualisiert werden kann, muss die alte Schlüsselversion aktiv sein (d. h. nicht deaktiviert oder gelöscht).

• Wenn im Quell-Dataset kein Wert für default_kms_key festgelegt ist, aber einzelne Tabellen im Quell-Dataset mit angewendetem CMEK vorhanden sind, können diese Tabellen im replizierten Dataset nicht abgefragt werden. So fragen Sie die Tabellen ab:

  • Fügen Sie dem Quell-Dataset einen default_kms_key-Wert hinzu.
  • Wenn Sie ein neues Replikat mit der DDL-Anweisung ALTER SCHEMA ADD REPLICA erstellen, legen Sie einen Wert für die Option replica_kms_key fest. Die CMEK-Tabellen können in der Zielregion abgefragt werden.

  Alle CMEK-Tabellen in der Zielregion verwenden unabhängig vom Schlüssel, der in der Quellregion verwendet wird, denselben replica_kms_key.

Replikat mit CMEK erstellen

Im folgenden Beispiel wird ein Replikat in der Region us-west1 mit einem festgelegten replica_kms_key-Wert erstellt. Gewähren Sie dem CMEK-Schlüssel die BigQuery-Dienstkonto-Berechtigung zum Verschlüsseln und Entschlüsseln.

-- Create a replica in the secondary region.
ALTER SCHEMA my_dataset
ADD REPLICA `us-west1`
OPTIONS(location='us-west1',
  replica_kms_key='my_us_west1_kms_key_name');

CMEK-Einschränkungen

Das Replizieren von Datasets mit angewendetem CMEK unterliegt folgenden Einschränkungen:

• Sie können den replizierten Cloud KMS-Schlüssel nicht mehr aktualisieren, nachdem das Replikat erstellt wurde.

• Sie können den Wert default_kms_key für das Quell-Dataset nicht aktualisieren, nachdem die Dataset-Replikate erstellt wurden.

• Wenn der angegebene replica_kms_key in der Zielregion nicht gültig ist, wird das Dataset nicht repliziert.

• CMEK-verschlüsselte Tabellen, die in die Zielregion repliziert werden, sind sichtbar, können jedoch nicht abgefragt oder geschrieben werden, da der Quell-CMEK in der Zielregion nicht erkannt wird.

Nächste Schritte

• Mit BigQuery-Reservierungen arbeiten.
• BigQuery-Zuverlässigkeitsfeatures