Regionenübergreifende Replikation und Notfallwiederherstellung

Wenn Sie den Lakehouse-Laufzeitkatalog über Regionen hinweg replizieren, können Sie Katalogmetadaten sichern und Ihre Arbeitslasten vor regionalen Ausfällen schützen. Im Rahmen des grenzenlosen Lakehouse können Sie die Notfallwiederherstellung verwenden, um ein Failover für Tabellen durchzuführen, die den Apache Iceberg REST-Katalogendpunkt verwenden.

Bei der Verwaltung von Failovern können Sie zwischen Soft-Failovern für geplante Tests oder Hard-Failovern zur Wiederherstellung des Dienstes wählen.

Funktionsweise

Der Lakehouse-Laufzeitkatalog wählt automatisch primäre und sekundäre Regionen für Katalogmetadaten aus. Die primäre Region verarbeitet alle Commit-Metadaten der Tabelle und repliziert sie dann zur Sicherung in die sekundäre Region.

Sie können die primäre und sekundäre Region für den Katalog jederzeit, insbesondere während eines Notfalls, mithilfe des Failover-Vorgangs wechseln. Dadurch wird die primäre Instanz für den Katalog und alle enthaltenen Namespaces und Tabellen gewechselt.

Regionsübergreifende Replikation

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

  • Datenreplikation: Cloud Storage repliziert Ihre Katalogdaten automatisch über mehrere Regionen hinweg, wenn Sie einen Dual-Region- oder Multi-Region-Bucket verwenden. Wenn ein regionaler Ausfall auftritt, bleiben Ihre Daten ohne Änderungen an den Speicherpfaden zugänglich.

  • Metastore-Replikation: Bei Iceberg-REST-Katalogendpunkten repliziert der Lakehouse-Laufzeitkatalog Ihren Metastore automatisch, wenn Sie einen Dual-Region-Bucket (oder einen benutzerdefinierten Dual-Region-Bucket) verwenden. Die Metastore-Replikation beginnt, wenn Sie den Katalog erstellen. Der Lakehouse-Laufzeitkatalog wählt eine primäre und eine sekundäre Region aus den in Ihrer Cloud Storage-Konfiguration definierten Regionen aus. Die primäre Region stellt alle Commit-Metadaten der Tabelle bereit und repliziert sie zur Sicherung in die sekundäre Region.

Notfallwiederherstellung mit Failover

Mit der Notfallwiederherstellungsfunktion können Sie die primäre und sekundäre Region für einen Katalog wechseln. Beim Failover-Vorgang wird die primäre Region für den Katalog und alle zugehörigen Namespaces und Tabellen gewechselt. Failovers haben zwei Modi: Soft-Failover und Hard-Failover.

  • Soft-Failover: Ein Soft-Failover verhindert Datenverlust. In diesem Modus akzeptiert die neue primäre Region erst dann Schreibvorgänge, wenn alle vorherigen Daten aus der vorherigen primären Region synchronisiert wurden. Verwenden Sie ein Soft-Failover für Notfallwiederherstellungstests oder andere geplante Szenarien.

  • Harter Failover: Bei einem harten Failover wird die Verfügbarkeit gegenüber der Datenkonsistenz priorisiert. Er ist darauf ausgelegt, den Dienst wiederherzustellen. In diesem Modus übernimmt immer die primäre Region und akzeptiert Schreibzugriffe, unabhängig vom aktuellen Status der primären Region. Wenn Sie beispielsweise ein hartes Failover verwenden, kann die neue primäre Region auch dann übernehmen, wenn die vorherige primäre Region nicht erreichbar ist.

Beschränkungen

Während sich dieses Feature in der Vorabversion befindet, werden mit REPLICATION_TIMESTAMP nur die Katalogmetadaten und nicht die Cloud Storage-Dateien erfasst. Informationen dazu, wie Sie den Datenverlust mit einer Untergrenze begrenzen können, finden Sie in der Cloud Storage-Dokumentation zur Datenverfügbarkeit und -beständigkeit.

Nächste Schritte