Regionsübergreifende Replikation und Notfallwiederherstellung verwenden

Auf dieser Seite wird beschrieben, wie Sie die regionenübergreifende Replikation und Notfallwiederherstellung von BigLake-Metastores verwenden.

Diese Funktion ist nur für Kataloge verfügbar, die Cloud Storage-Buckets mit Dual-Region oder Multi-Region verwenden.

Hinweise

  1. Verify that billing is enabled for your Google Cloud project.

  2. Enable the BigLake API.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the API

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zur Verwendung des Iceberg-REST-Katalogs im BigLake-Metastore benötigen:

  • Administrativen Aufgaben ausführen, z. B. den Nutzerzugriff auf den Katalog, den Speicherzugriff und den Modus für die Bereitstellung von Anmeldedaten des Katalogs verwalten:
  • Tabellendaten im Credential Vending-Modus lesen: BigLake-Betrachter (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:Sie haben die Wahl zwischen einem Soft-Failover (am besten für geplante Wartungsarbeiten) und einem Hard-Failover (am besten für die Notfallwiederherstellung).
  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 alpha biglake iceberg catalogs describe-Befehl aus, um die Regionen zu ermitteln, in denen Ihr Katalog repliziert wird.

gcloud alpha 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 alpha biglake iceberg failover:

gcloud alpha 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 alpha biglake iceberg failover-Befehl aus, um einen Soft-Failover einzuleiten:

gcloud alpha 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 alpha biglake iceberg failover-Befehl aus, um einen Hard-Failover zu starten:

gcloud alpha 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 den Failover-Prozess unabhängig von einer Replikationsverzögerung erzwingen möchten, legen Sie diesen Zeitstempel auf ein Datum fest, das weit in der Vergangenheit liegt.

Nächste Schritte