Zur verwalteten Notfallwiederherstellung migrieren

Auf dieser Seite wird beschrieben, wie Sie von der regionsübergreifenden BigQuery-Replikation zur von BigQuery verwalteten Notfallwiederherstellung migrieren.

Übersicht

Die regionenübergreifende Replikation (Cross-Region Replication, CRR) und die verwaltete Notfallwiederherstellung (Disaster Recovery, DR) von BigQuery sind beide Funktionen, die die Datenverfügbarkeit und die Notfallwiederherstellung verbessern sollen. Regionale Ausfälle werden jedoch unterschiedlich behandelt. Bei CRR kann das sekundäre Replikat nicht hochgestuft werden, wenn die primäre Region nicht verfügbar ist. Im Gegensatz dazu bietet DR einen umfassenderen Schutz, da ein Failover zum sekundären Replikat auch dann möglich ist, wenn die primäre Region nicht verfügbar ist. Bei CRR wird nur der Speicher repliziert, bei DR werden sowohl Speicher- als auch Rechenkapazität repliziert.

In der folgenden Tabelle werden die Funktionen von CRR und DR beschrieben:

Funktion CRR DR
Erstreplikation Verwendet CRR, um das Dataset anfänglich zu replizieren. Der anfängliche Ladevorgang wird mit CRR repliziert, bevor ein CRR-Dataset zu einem DR-Dataset migriert wird.
Angebotsreplikation Verwendet die Standardreplikation. Verwendet die Turboreplikation.
Ablauf von Werbeaktionen Wird auf Dataset-Ebene beworben. Wird auf Reservierungsebene gefördert (Reservierungs-Failover und Dataset-Promotion). An eine Failover-Reservierung können viele Datasets angehängt werden. Die Bewerbung auf Dataset-Ebene ist mit DR nicht verfügbar.
Ausführung von Angeboten Über die Benutzeroberfläche oder einen SQL-basierten DDL-Befehl für jedes Dataset. Es gibt keine Unterstützung für CLI, Clientbibliotheken, API oder Terraform. Über die Benutzeroberfläche oder einen SQL-basierten DDL-Befehl für jede EPE-Reservierung. CLI, Clientbibliotheken, API oder Terraform werden nicht unterstützt.
Failover-Modus Weicher Failover. Harter Failover
Versionsanforderung Jedes Kapazitätsmodell. Enterprise Plus-Version
Beschränkungen Einschränkungen bei der CRR Umfasst sowohl Einschränkungen für die Conversion-Rate als auch Einschränkungen für die Reichweite.
Schreibzugriff Jobs, die mit einem beliebigen Kapazitätsmodell ausgeführt werden, können in der primären Region in replizierte Datasets schreiben. Sekundär ist immer schreibgeschützt. Nur die Jobs, die unter Enterprise Plus-Reservierungen ausgeführt werden, können in die replizierten Datasets in der primären Region schreiben. Sekundäre Dataset- und Reservierungsreplikate sind immer schreibgeschützt.
Lesezugriff Jobs, die mit einem beliebigen Kapazitätsmodell ausgeführt werden, können Daten aus replizierten Datasets lesen. Jobs, die mit einem beliebigen Kapazitätsmodell ausgeführt werden, können Daten aus replizierten Datasets lesen.

Auswirkungen der Migration

In den folgenden Abschnitten finden Sie einen Überblick über die Kosten- und Funktionsänderungen, die bei der Migration zu DR auftreten.

Auswirkungen auf die Kosten

Berücksichtigen Sie bei der Migration von CRR zu DR die folgenden Auswirkungen auf die Kosten:

  • Die Notfallwiederherstellung unterstützt nur Schreibzugriff über die Enterprise Plus-Version, was höhere Rechenkosten verursacht. Sie können Daten aus jedem Kapazitätsmodell lesen. Die Lesekosten für bestehende Jobs ändern sich also nicht.

  • Bei DR wird die Turboreplikation verwendet, für die je nach Regionenpaar zusätzliche Kosten anfallen.

  • Die Speicherpreise sind für CRR und DR gleich.

Weitere Informationen zu Preisen finden Sie unter Preise.

Auswirkungen auf die Funktionen

Berücksichtigen Sie bei der Migration von CRR zu DR die folgenden Auswirkungen auf die Funktionen:

  • DR unterstützt nur Failover auf Reservierungsebene. Alle vorhandenen Jobs, die auf Failover auf Dataset-Ebene angewiesen sind, schlagen fehl.

  • Nur Enterprise Plus-Abfragen können in das Dataset schreiben, nachdem es an die DR-Reservierung angehängt wurde. Alle vorhandenen Schreibjobs, für deren Rechenkapazität keine Enterprise Plus-Version verwendet wird, schlagen fehl.

Hinweise

Bevor Sie mit der Migration beginnen, sollten Sie sich mit den Konzepten in regionenübergreifende Replikation und verwaltete Notfallwiederherstellung vertraut machen.

Für die Migration zu DR müssen die folgenden Voraussetzungen erfüllt sein:

  • Sie haben ein aktives Google Cloud Projekt, für das BigQuery aktiviert ist.

  • Sie haben Datasets mit CRR erstellt und repliziert.

  • Die Datasets haben dieselben primären und sekundären Standorte, die Sie für DR verwenden möchten.

  • Sie haben die erforderlichen Berechtigungen für die Arbeit mit DR. Weitere Informationen zu Berechtigungen finden Sie unter Vorbereitung.

Von CRR zu DR migrieren

In den folgenden Abschnitten wird beschrieben, wie Sie Ihre Datasets von CRR zu DR migrieren. Es wird davon ausgegangen, dass Sie Ihre Datasets bereits für CRR konfiguriert haben.

Failover-Reservierung erstellen

Zur Aktivierung der Notfallwiederherstellung müssen Sie eine Failover-Reservierung in der primären Region erstellen. Konfigurieren Sie Ihre Reservierung mit der entsprechenden primären und sekundären Region. Die primäre und die sekundäre Region müssen mit den Regionen aller CRR-Datasets übereinstimmen, die Sie zu DR migrieren möchten. Wählen Sie eine der folgenden Optionen aus, um eine Failover-Reservierung zu erstellen:

Console

  1. Rufen Sie in der Google Cloud Console die Seite BigQuery auf.

    BigQuery aufrufen

  2. Klicken Sie im Navigationsmenü auf Kapazitätsverwaltung und dann auf Reservierung erstellen.

  3. Geben Sie im Feld Name der Reservierung einen Namen für die Reservierung ein.

  4. Wählen Sie in der Liste Standort einen Standort aus.

  5. Wählen Sie in der Liste Version die Enterprise Plus-Version aus.

  6. Wählen Sie in der Liste Maximale Reservierungsgröße die maximale Reservierungsgröße aus.

  7. Optional: Geben Sie im Feld Referenz-Slots die Anzahl der Referenz-Slots für die Reservierung ein.

    Die Anzahl der verfügbaren Autoscaling-Slots wird bestimmt, indem der Wert für Referenz-Slots vom Wert Maximale Reservierungsgröße abgezogen wird. Wenn Sie beispielsweise eine Reservierung mit 100 Referenz-Slots und einer maximalen Reservierungsgröße von 400 erstellen, hat Ihre Reservierung 300 Autoscaling-Slots. Weitere Informationen zu Referenz-Slots finden Sie unter Reservierungen mit Slots für Referenz und Autoscaling verwenden.

  8. Wählen Sie in der Liste Sekundärer Standort den sekundären Standort aus.

  9. Wenn Sie die Freigabe inaktiver Slots deaktivieren und nur die angegebene Slotkapazität verwenden möchten, klicken Sie auf die Schaltfläche Inaktive Slots ignorieren.

  10. Klicken Sie zum Erweitern des Abschnitts Erweiterte Einstellungen auf den Erweiterungspfeil.

  11. Optional: Um die Zielnebenläufigkeit von Jobs festzulegen, klicken und aktivieren Sie die Schaltfläche Automatische Zielnebenläufigkeit von Jobs überschreiben und geben Sie einen Wert für die Zielnebenläufigkeit von Jobs ein. Die Aufschlüsselung der Slots wird in der Tabelle Kostenschätzung angezeigt. In der Tabelle Kapazitätsübersicht wird eine Zusammenfassung der Reservierung angezeigt.

  12. Klicken Sie auf Speichern.

Die neue Reservierung ist auf dem Tab Slot-Reservierungen zu sehen.

SQL

Verwenden Sie zum Erstellen einer Reservierung die DDL-Anweisung CREATE RESERVATION.

  1. Rufen Sie in der Google Cloud Console die Seite BigQuery auf.

    BigQuery aufrufen

  2. Geben Sie im Abfrageeditor die folgende Anweisung ein:

    CREATE RESERVATION
  `ADMIN_PROJECT_ID.region-LOCATION.RESERVATION_NAME`
OPTIONS (
  slot_capacity = NUMBER_OF_BASELINE_SLOTS,
  edition = ENTERPRISE_PLUS,
  secondary_location = SECONDARY_LOCATION);

    Ersetzen Sie Folgendes:

    • ADMIN_PROJECT_ID: die Projekt-ID des Administrationsprojekts, dem die Reservierungsressource gehört
    • LOCATION: Der Standort der Reservierung. Wenn Sie einen BigQuery Omni-Standort auswählen, ist Ihre Versionsoption auf die Enterprise-Version beschränkt.

    • RESERVATION_NAME: der Name der Reservierung

      Der Name muss mit einem Kleinbuchstaben oder einer Zahl beginnen und enden. Er darf nur Kleinbuchstaben, Ziffern und Bindestriche enthalten.

    • NUMBER_OF_BASELINE_SLOTS: die Anzahl der Slots, die der Reservierung zugewiesen werden sollen. Sie können die Optionen slot_capacity und edition nicht in derselben Reservierung festlegen.
    • SECONDARY_LOCATION: der sekundäre Standort der Reservierung. Bei einem Ausfall wird für alle mit dieser Reservierung verknüpften Datasets ein Failover zu diesem Standort ausgeführt.

  3. Klicken Sie auf Ausführen.

Informationen zum Ausführen von Abfragen finden Sie unter Interaktive Abfrage ausführen.

Dataset an die Reservierung anhängen

Nachdem Sie die Failover-Reservierung erstellt haben, hängen Sie Ihr regionsübergreifendes Dataset oder Ihre regionsübergreifenden Datasets an die Reservierung an. Dadurch wird das Failover für alle angehängten Datasets aktiviert. Wählen Sie eine der folgenden Optionen aus, um das Dataset an die Reservierung anzuhängen:

Console

  1. Rufen Sie in der Google Cloud Console die Seite BigQuery auf.

    BigQuery aufrufen

  2. Klicken Sie im Navigationsmenü auf Kapazitätsverwaltung und dann auf den Tab Slot-Reservierungen.

  3. Klicken Sie auf die Reservierung, an die Sie ein Dataset anhängen möchten.

  4. Klicken Sie auf den Tab Notfallwiederherstellung.

  5. Klicken Sie auf Failover-Dataset hinzufügen.

  6. Geben Sie den Namen des Datasets ein, das Sie mit der Reservierung verknüpfen möchten.

  7. Klicken Sie auf Hinzufügen.

SQL

Mit der DDL-Anweisung ALTER SCHEMA SET OPTIONS können Sie ein Dataset an eine Reservierung anhängen.

  1. Rufen Sie in der Google Cloud Console die Seite BigQuery auf.

    BigQuery aufrufen

  2. Geben Sie im Abfrageeditor die folgende Anweisung ein:

    ALTER SCHEMA
  `DATASET_NAME`
SET OPTIONS (
  failover_reservation = ADMIN_PROJECT_ID.RESERVATION_NAME);

    Ersetzen Sie Folgendes:

    • DATASET_NAME: der Name des Datasets

    • ADMIN_PROJECT_ID.RESERVATION_NAME: der Name der Reservierung, der Sie das Dataset zuordnen möchten.

  3. Klicken Sie auf Ausführen.

Informationen zum Ausführen von Abfragen finden Sie unter Interaktive Abfrage ausführen.

Konfiguration prüfen

Fragen Sie die Ansicht INFORMATION_SCHEMA.SCHEMATA_REPLICAS ab, um den Status Ihrer Konfiguration zu prüfen.

PROJECT_ID.`region-REGION`.INFORMATION_SCHEMA.SCHEMATA_REPLICAS[_BY_PROJECT]

Prüfen Sie, ob die Datasets an die richtige Reservierung in den richtigen Regionen angehängt sind.

Dabei gilt:
  • Optional: PROJECT_ID: die ID Ihres Google Cloud -Projekts. Wenn keine Angabe erfolgt, wird das Standardprojekt verwendet.
  • REGION: ist ein beliebiger Dataset-Regionsname. Beispiel: `region-us`

Beispiele

Im folgenden Beispiel werden die Schritte für die Migration von CRR zu DR mit praktischen Beispielen in GoogleSQL beschrieben. Nehmen wir für dieses Beispiel Folgendes an:

  • Sie arbeiten in einem Projekt mit dem Namen myproject.

  • Sie haben bereits ein Dataset mit dem Namen mydataset erstellt und mit CRR konfiguriert.

  • Die primäre Region von mydataset ist us-central1 und die sekundäre Region ist us-west1.

Wenn Sie Ihr Dataset zur Notfallwiederherstellung migrieren möchten, müssen Sie zuerst eine Reservierung mit der Enterprise Plus-Version erstellen. In diesem Beispiel lautet der Name der Reservierung myreservation.

CREATE RESERVATION `myproject.region-us-central1.myreservation`
OPTIONS (
  slot_capacity = 0,
  edition = ENTERPRISE_PLUS,
  autoscale_max_slots = 50,
  secondary_location = 'us-west-1');

Nachdem Sie die Reservierung erstellt haben, können Sie das Dataset daran anhängen. Im folgenden Beispiel wird das Dataset an die Reservierung angehängt:

ALTER SCHEMA
  `myproject.mydataset`
SET OPTIONS (
  failover_reservation = 'myproject.myreservation');

Prüfen Sie dann, ob das Dataset erfolgreich angehängt wurde.

SELECT
  failover_reservation_project_id,failover_reservation_name,
FROM
 `myproject`.`region-us-west1`.INFORMATION_SCHEMA.SCHEMATA_REPLICAS
WHERE
 schema_name='mydataset';

Die Ergebnisse dieser Abfrage sollten in etwa so aussehen:

+---------------------------------+---------------------------+
| failover_reservation_project_id | failover_reservation_name |
+---------------------------------+---------------------------+
| myproject                       | myreservation             |
| myproject                       | myreservation             |
+---------------------------------+---------------------------+

Nächste Schritte