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 von Cloud Storage-Buckets mit Dual-Region oder Multi-Region unterstützt werden.

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 IAM-Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin), die die Berechtigung serviceusage.services.enable enthält. Weitere 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 zur Verwendung des Iceberg-REST-Katalogendpunkts im Lakehouse-Laufzeitkatalog benötigen:

  • Administrativen Aufgaben ausführen, z. B. den Zugriff von Nutzern auf den Katalog, den Speicherzugriff und den Modus für die Bereitstellung von Anmeldedaten des Katalogs verwalten:
  • Tabellendaten im Credential Vending-Modus lesen: BigLake Viewer (roles/biglake.viewer) für das Projekt
  • Tabellendaten im Credential Vending-Modus 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 aktuellen primären und sekundären Regionen, um die Zielregion für das Failover zu bestimmen.
  2. Synchronisierungsstatus prüfen:Prüfen Sie den aktuellen Status Ihrer primären und sekundären Regionen, um sicherzustellen, dass sie für eine Umstellung bereit sind.
  3. Failover-Modus auswählen:Wählen Sie zwischen einem Soft Failover (am besten für geplante Wartungsarbeiten) und einem Hard Failover (am besten für die Notfallwiederherstellung) aus.
  4. Failover initiieren:Führen Sie den Befehl aus, der Ihrem ausgewählten Modus entspricht, um die primäre und sekundäre Region zu tauschen.

Auf Failover vorbereiten

Ermitteln Sie Ihre aktuelle primäre Region und prüfen Sie den Synchronisierungsstatus Ihrer sekundären Region. Initialisieren Sie dann das 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

Bevor Sie einen Failover einleiten, prüfen Sie den Synchronisierungsstatus des sekundären Replikats mit dem Befehl gcloud biglake iceberg catalogs failover:

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

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

Weicher Failover

Führen Sie den folgenden gcloud biglake iceberg catalogs failover-Befehl aus, um einen Soft-Failover zu starten:

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 Hard-Failover zu starten:

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. Bei der Replikation wird geprüft, ob das Replikat alle bis zu diesem Zeitpunkt übertragenen Daten enthält. Wenn das Replikat nicht alle Daten enthält, die vor diesem Zeitstempel übernommen wurden, schlägt der Befehl fehl. Wenn Sie das Failover unabhängig von einer Replikationsverzögerung erzwingen möchten, legen Sie für diesen Zeitstempel ein Datum fest, das weit in der Vergangenheit liegt. Hinweis: Während sich diese Funktion in der Vorschauphase befindet, werden mit REPLICATION_TIMESTAMP nur die Katalogmetadaten und nicht die Cloud Storage-Dateien erfasst. Informationen dazu, wie Sie Datenverlust auf ein Minimum reduzieren können, finden Sie in der Cloud Storage-Dokumentation unter Datenverfügbarkeit und ‑beständigkeit.

Nächste Schritte