Regionenübergreifende Replikation und Notfallwiederherstellung

Die regionenübergreifende Replikation und Notfallwiederherstellung für den Lakehouse-Laufzeitkatalog schützt vor regionalen Ausfällen. Im Rahmen von Lakehouse für Apache Iceberg ermöglicht diese Funktion das Failover für Tabellen, die den Apache Iceberg REST-Katalog-Endpunkt verwenden.

Bei der Verwaltung von Failovers können Sie zwischen Soft Failovers für geplante Tests oder Hard Failovers wählen, um den Dienst schnell wiederherzustellen.

Funktionsweise

Im Lakehouse-Laufzeitkatalog werden automatisch primäre und sekundäre Regionen für Katalogmetadaten ausgewählt. In der primären Region werden alle Commit-Metadaten für Tabellen verarbeitet und dann zur Sicherung in die sekundäre Region repliziert.

Sie können die primäre und die sekundäre Region für den Katalog jederzeit, insbesondere im Katastrophenfall, mit dem Failover-Vorgang tauschen. Bei dieser Aktion wird der primäre Katalog für den Katalog und alle darin enthaltenen Namespaces und Tabellen umgeschaltet.

Regionsübergreifende Replikation

Die regionenübergreifende Replikation umfasst zwei Hauptkomponenten: Datenreplikation und Metastore-Replikation. Die Notfallwiederherstellungsfunktion basiert auf der regionsübergreifenden Replikation, um Failover zu ermöglichen.

  • Datenreplikation: Cloud Storage repliziert Ihre Katalogdaten automatisch über mehrere Regionen hinweg, wenn Sie einen Bucket mit zwei oder mehreren Regionen verwenden. Bei einem regionalen Ausfall bleiben Ihre Daten ohne Änderungen an den Speicherpfaden zugänglich.

  • Metastore-Replikation: Bei Iceberg-REST-Katalogendpunkten wird Ihr Metastore automatisch vom Lakehouse-Laufzeitkatalog repliziert, wenn Sie einen Dual-Region-Bucket (oder benutzerdefinierten Dual-Region-Bucket) verwenden. Die Metastore-Replikation beginnt, wenn Sie den Katalog erstellen. Im Lakehouse-Laufzeitkatalog wird eine primäre und eine sekundäre Region aus den Regionen ausgewählt, die in Ihrer Cloud Storage-Konfiguration definiert sind. In der primären Region werden alle Commit-Metadaten für Tabellen bereitgestellt und zur Sicherung in die sekundäre Region repliziert.

Notfallwiederherstellung mit Failover

Mit der Notfallwiederherstellungsfunktion können Sie die primäre und sekundäre Region für einen Katalog tauschen. Beim Failover wird die primäre Region für den Katalog und alle zugehörigen Namespaces und Tabellen umgeschaltet. Es gibt zwei Arten von Failover: Soft Failover und Hard Failover.

  • Soft Failover: Ein Soft Failover verhindert Datenverlust. In diesem Modus beginnt die neue primäre Region erst dann mit dem Akzeptieren von Schreibvorgängen, wenn alle vorherigen Daten aus der vorherigen primären Region synchronisiert wurden. Verwenden Sie ein Soft-Failover für Tests zur Notfallwiederherstellung oder andere geplante Szenarien.

  • Harter Failover: Bei einem harten Failover wird die Verfügbarkeit über die Datenkonsistenz gestellt. Er soll den Dienst wiederherstellen. In diesem Modus übernimmt immer die primäre Region und akzeptiert Schreibtraffic, unabhängig vom aktuellen Status der primären Region. Bei einem harten Failover kann die neue primäre Region beispielsweise die Kontrolle übernehmen, auch wenn die vorherige primäre Region nicht erreichbar ist.

Beschränkungen

Während sich diese Funktion in der Vorschauphase befindet, werden vom REPLICATION_TIMESTAMP nur die Katalogmetadaten und nicht die Cloud Storage-Dateien erfasst. Informationen zum Minimieren des Datenverlusts finden Sie in der Cloud Storage-Dokumentation unter Datenverfügbarkeit und ‑beständigkeit.

Nächste Schritte