Regionsübergreifende Replikation und Notfallwiederherstellung verwenden

Lakehouse for Apache Iceberg unterstützt die regionenübergreifende Replikation und Notfallwiederherstellung für Katalogmetadaten.

Für diese Konfiguration sind Kataloge erforderlich, die durch Cloud Storage Buckets mit dualer oder multiregionaler Konfiguration gesichert sind.

Hinweis

  1. Prüfen Sie, ob die Abrechnung für Ihr Google Cloud Projekt aktiviert ist.

  2. Aktivieren Sie die BigLake API.

    Rollen, die zum Aktivieren von APIs erforderlich sind

    Zum Aktivieren von APIs benötigen Sie die Berechtigung serviceusage.services.enable. Wenn Sie das Projekt erstellt haben, haben Sie diese Berechtigung wahrscheinlich bereits über die Rolle „Inhaber“ (roles/owner). Andernfalls können Sie diese Berechtigung über die Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin) erhalten. Informationen zum Zuweisen von Rollen.

    API aktivieren

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Verwenden des Iceberg-REST-Katalogendpunkts im Lakehouse-Laufzeitkatalog benötigen:

  • Verwaltungsaufgaben ausführen, z. B. den Nutzerzugriff auf den Katalog, den Speicherzugriff und den Modus für die Bereitstellung von Anmeldedaten für den Katalog verwalten:
  • Tabellendaten im Modus für die Bereitstellung von Anmeldedaten lesen: BigLake-Betrachter (roles/biglake.viewer) für das Projekt
  • Tabellendaten im Modus für die Bereitstellung von Anmeldedaten schreiben: BigLake-Editor (roles/biglake.editor) für das Projekt
  • Katalogressourcen und Tabellendaten im Modus ohne Bereitstellung von Anmeldedaten lesen:
  • Katalogressourcen verwalten und Tabellendaten im Modus ohne Bereitstellung von Anmeldedaten schreiben:

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Workflow für Replikation und Notfallwiederherstellung

So verwenden Sie die regionenübergreifende Replikation und Notfallwiederherstellung:

  1. Replikationsstatus ansehen:Ermitteln Sie Ihre aktuelle primäre und sekundäre Region, um die Zielregion für den Failover zu bestimmen.
  2. Synchronisierungsstatus prüfen:Prüfen Sie den aktuellen Status Ihrer primären und sekundären Region, um sicherzustellen, dass sie für eine Umstellung bereit sind.
  3. Failover-Modus auswählen: Wählen Sie zwischen einem weichen Failover (am besten für geplante Wartungsarbeiten geeignet) und einem harten Failover (am besten für die Notfall wiederherstellung geeignet).
  4. Failover initialisieren:Führen Sie den Befehl aus, der dem ausgewählten Modus entspricht, um Ihre primäre und sekundäre Region zu wechseln.

Failover vorbereiten

Ermitteln Sie Ihre aktuelle primäre Region und prüfen Sie den Synchronisierungsstatus Ihrer sekundären Region. Initialisieren Sie dann den Failover.

Replikationsstatus ansehen

Führen Sie den folgenden gcloud biglake iceberg catalogs describe-Befehl aus, um die Regionen zu ermitteln, in denen Ihr Katalog repliziert wird.

gcloud biglake iceberg catalogs describe CATALOG_NAME

Ersetzen Sie CATALOG_NAME durch den Namen Ihres Katalogs.

Synchronisierungsstatus prüfen

Prüfen Sie vor dem Initialisieren eines Failovers den Synchronisierungsstatus Ihres sekundären Replikats mit dem gcloud biglake iceberg catalogs failover Befehl:

gcloud biglake iceberg catalogs failover CATALOG_NAME \
    --validate_only \
    --primary-replica PRIMARY_REPLICA_REGION

Ersetzen Sie Folgendes:

  • CATALOG_NAME: der Name Ihres Katalogs.
  • PRIMARY_REPLICA_REGION: die Region, die als neues primäres Replikat festgelegt werden soll.

Failover auslösen

Die Notfallwiederherstellungsfunktion verwendet die Metastore-Replikation, um primäre und sekundäre Regionen festzulegen. Alle Metadaten für den Tabellen-Commit werden aus der primären Region bereitgestellt und in die sekundäre Region repliziert. Sie können die primäre und sekundäre Region für den Katalog mit dem Failover-Vorgang wechseln.

Weicher Failover

Führen Sie den folgenden gcloud biglake iceberg catalogs failover Befehl aus, um einen weichen Failover zu initialisieren:

gcloud biglake iceberg catalogs failover CATALOG_NAME \
    --primary-replica PRIMARY_REPLICA_REGION

Ersetzen Sie Folgendes:

  • CATALOG_NAME: der Name Ihres Katalogs.
  • PRIMARY_REPLICA_REGION: die Region, die als neues primäres Replikat festgelegt werden soll.

Harter Failover

Führen Sie den folgenden gcloud biglake iceberg catalogs failover Befehl aus, um einen harten Failover zu initialisieren:

gcloud biglake iceberg catalogs failover CATALOG_NAME \
    --primary-replica PRIMARY_REPLICA_REGION \
    --conditional-failover-replication-time=REPLICATION_TIMESTAMP

Ersetzen Sie Folgendes:

  • CATALOG_NAME: der Name Ihres Katalogs.
  • PRIMARY_REPLICA_REGION: die Region, die als neues primäres Replikat festgelegt werden soll.
  • REPLICATION_TIMESTAMP: ein RFC 3339-Zeitstempel, der als Prüfpunkt für die Replikation dient. Beim Replikationsvorgang wird geprüft, ob das Replikat alle Daten enthält, die bis zu diesem Zeitpunkt per Commit festgelegt wurden. Wenn das Replikat nicht alle Daten enthält, die vor diesem Zeitstempel per Commit festgelegt wurden, schlägt der Befehl fehl. Wenn Sie den Failover-Vorgang unabhängig von einer Replikationsverzögerung erzwingen möchten, legen Sie diesen Zeitstempel auf ein Datum in der fernen Vergangenheit fest. Hinweis: Während sich diese Funktion in der Vorschauphase befindet, verfolgt REPLICATION_TIMESTAMP nur die Katalogmetadaten und nicht die Cloud Storage-Dateien. Informationen dazu, wie Sie Datenverluste auf ein Minimum beschränken können, finden Sie in der Dokumentation zur Datenverfügbarkeit und ‑beständigkeit in Cloud Storage.

Nächste Schritte