Unterstützung von Freigabeangeboten für Geschäftskontinuität und Notfallwiederherstellung¶

Anbietende können Freigabeangebote und ihre Abhängigkeiten – wie beispielsweise Freigaben und Datenbanken – in Kontoreplikations- und Failover-Gruppen einbinden. Bei Failover-Gruppen stützt sich das Freigabeangebot bei einer Beeinträchtigung oder einem Ausfall auf Failover-Gruppen für die Datenreplikation und Notfallwiederherstellung.

Bemerkung

Dieses Feature ist nur für Freigabeangebote verfügbar, bei denen die automatische Ausführung aktiviert ist.
Überprüfen Sie den Abschnitt Verhalten, Hinweise und Einschränkungen, bevor Sie dieses Feature verwenden.

Begriffe¶

Primäre Freigabeangebote: Freigabeangebote in der primären Failover-Gruppe
Sekundäre Freigabeangebote: Freigabeangebote in der sekundären Failover-Gruppe

Verstehen der Notwendigkeit von Geschäftskontinuität und Notfallwiederherstellung¶

Im Falle eines Ausfalls in der primären Region wird Geschäftskontinuität und Notfallwiederherstellung (BCDR) für Anbietende entscheidend.

Anbietende müssen ihre Datenprodukte weiterhin mit minimalen Unterbrechungen während eines Ausfalls unterstützen.
Anbietende müssen Service Level Agreements (SLAs ) in Bezug aufRTO (Recovery Time Objective) undRPO (Recovery Point Objective) zur Vermeidung von finanziellen Strafen einhalten.
Anbietende müssen für den Fall eines Ausfalls Replikate ihrer Daten in sekundären Regionen aufbewahren.

Manuelle Konfiguration für Failover und Wiederherstellung¶

Anbietende, die keine Freigabeangebote zu ihren Failover-Gruppen hinzufügen, haben höhere Wiederherstellungszeiten und bieten Ihren Verbrauchenden veraltete Informationen. Ohne BCDR müssen Anbietende nach dem Failover die Angebote in den sekundären Regionen neu erstellen. Anschließend müssen die Verbrauchende wieder neue Freigabeangebots-URLs einbinden. Diese manuelle Replikation verursacht massive Unterbrechungen bei ETL-Pipelines und -Anwendungen, was zu längeren Ausfallzeiten für Verbrauchende und zusätzlichen Datenübertragungskosten für Anbietende führt.

Automatisiertes Failover und Wiederherstellung¶

BCDR für Freigabeangebote verbessert die Bereitschaft des Unternehmens und verringert Unterbrechungen durch einen Ausfall.

BCDR für Freigabeangebote beseitigt die Notwendigkeit für Anbietende, Freigabeangebote nach einem Failover neu zu erstellen.
Die neue primäre Region repliziert nicht erneut in die Secure Share Area (SSA )-Konten, was Datenübertragungskosten spart, da nur inkrementelle Änderungen in die SSA-Konten repliziert werden.

Mit BCDR-Unterstützung für Freigabeangebote nach einem Failover:

Verbrauchende haben weiterhin und ohne Ausfallzeiten Zugriff auf die Daten der Anbietenden.
Anbietende können neue Verbraucherregionen aus der neuen primären Region erreichen.
Anbietende können weiterhin die Anforderungen an die Aktualität der Verbraucherdaten erfüllen, da das Freigabeangebot von der neuen primären Region aktualisiert wird.

BCDR-Workflow für Freigabeangebote¶

Ein typischer BCDR-Workflow für Freigabeangebote ist wie folgt:

Ein Ausfall in der Region wirkt sich auf die primäre Region aus.
- Während die primäre Region ausgefallen ist, können Freigabeangebote in Verbraucherregionen nicht aktualisiert werden. Infolgedessen arbeiten die Verbrauchende mit veralteten Daten.
Der Admin für Datenwiederherstellungen initiiert das Runbook der Organisation.
Der Admin erhält die Genehmigung zum Failover in die sekundäre Region.
- Diese sekundäre Region wird zur neuen primären Region.
- Das Replikat in der Failover-Gruppe wird zur neuen Informationsquelle für alle Objekte.
Der Admin aktualisiert die neue primäre Region mit den neuesten Aktualisierungen aus den Datenquellen, wie z. B. externen Tabellen und ETL-Pipelines.
- Der Admin erhält einen Snapshot der Objekte in der neuen primären Region, um zu überprüfen, ob diese die aktuellsten Daten enthält.
- Der Admin überprüft die neue primäre Region, um festzustellen, ob sie für die Produktion bereit ist.
- Nach Abschluss des Failovers funktioniert die automatische Ausführung wieder ab dem nächsten Aktualisierungsintervall aus der neuen primären Region.

Bemerkung

Der Admin kann den SHOW LISTINGS IN FAILOVER GROUP-Befehl verwenden, um zu bestätigen, dass die Freigabeangebote für die Produktion bereit sind.

BCDR-Auswahlkriterien¶

BCDR wird in folgenden Fällen nicht unterstützt:

Das Freigabeangebot befindet sich im Entwurfsstatus.
Das Freigabeangebot wird durch einen Stagingbereich unterstützt.
Das Freigabeangebot ist ein kostenpflichtiges Freigabeangebot.
Für das Freigabeangebot ist die automatische Ausführung nicht aktiviert.
Das Freigabeangebot ist ein Snowflake Native App-Freigabeangebot.

Verhalten, Hinweise und Einschränkungen¶

Lesen Sie die folgenden Abschnitte, um das Verhalten, die Hinweise und die Einschränkungen von BCDR für Freigabeangebote zu verstehen.

Verhalten¶

Wenn eine sekundäre Failover-Gruppe gelöscht wird, werden die sekundären Freigabeangebote in der Failover-Gruppe automatisch gelöscht.

Hinweise¶

Der Failover von extern verwalteten Iceberg-Tabellen wird derzeit nicht unterstützt, obwohl sie für die automatische Ausführung unterstützt werden. Der Failover von verwalteten Iceberg-Tabellen befindet sich derzeit in der öffentlichen Vorschau.
Einige Features werden für den Failover hinsichtlich der Datenbank möglicherweise nicht unterstützt, können aber für den Failover hinsichtlich des Freigabeangebots unterstützt werden. Die nicht unterstützten Objekte werden bei der Replikation ignoriert.

Einschränkungen¶

Stellen Sie sicher, dass Sie die folgenden Einschränkungen verstehen, bevor Sie BCDR für Freigabeangebote konfigurieren:

Vollständige Teilmengeneinschränkungen (Alles-oder-Nichts-Regel)
Anforderungen an den Objekttyp der Failover-Gruppe
Einschränkungen für die Einrichtung der automatischen Ausführung von Freigabeangeboten
Einschränkungen für Freigabeangebote auf dem Internal Marketplace
Einschränkungen bei der Profilreplikation
Einschränkungen für schreibgeschützte sekundäre Freigabeangebote

Vollständige Teilmengeneinschränkungen (Alles-oder-Nichts-Regel)¶

Wenn beim Hinzufügen eines Objekts zu einer Failover-Gruppe ein Objekt von einem Freigabeangebot referenziert wird, bei dem die automatische Ausführung aktiviert ist, müssen alle Objekte, die von demselben Freigabeangebot referenziert werden, in derselben Failover-Gruppe enthalten sein.
Wenn beim Entfernen eines Objekts aus einer Failover-Gruppe ein Objekt von einem Freigabeangebot referenziert wird, bei dem die automatische Ausführung aktiviert ist, müssen alle Objekte, die von demselben Freigabeangebot referenziert werden, zusammen entfernt werden.

Anforderungen an den Objekttyp der Failover-Gruppe¶

Wenn eine Failover-Gruppe Datenbanken oder Freigaben enthält, die von Freigabeangeboten referenziert werden, die die automatische Ausführung aktiviert haben, muss die Failover-Gruppe LISTINGS in ihrem OBJECT_TYPES-Parameter enthalten. Beispiel:

CREATE FAILOVER GROUP provider_dr_fg
  OBJECT_TYPES = DATABASES, LISTINGS
  ...

Einschränkungen für die Einrichtung der automatischen Ausführung von Freigabeangeboten¶

Bevor Sie die automatische Ausführung für ein Freigabeangebot aktivieren oder ein Angebot veröffentlichen, bei dem die automatische Ausführung aktiviert ist, müssen alle Abhängigkeiten von einem Angebot – einschließlich Freigaben und Datenbanken – in einer Failover-Gruppe konfiguriert werden, die den Objekttyp LISTINGS enthält.
Die automatische Ausführung muss für das zweite Konto manuell aktiviert werden (falls sie nicht bereits aktiviert ist). Weitere Informationen dazu finden Sie unter SYSTEM$ENABLE_GLOBAL_DATA_SHARING_FOR_ACCOUNT.
Wenn die REFERENCE_USAGE-Berechtigung von Freigabeangeboten verwendet wird, können auch Objekte als Teil der Teilmenge gezählt werden, die nicht direkt mit dem Freigabeangebot zusammenhängen, aber unter die vollständige Teilmengeneinschränkung fallen.

Einschränkungen für Freigabeangebote auf dem Internal Marketplace¶

Die folgenden Einschränkungen gelten für Freigabeangebote auf dem Internal Marketplace (Organisations-Freigabeangebote):

Genehmigungs-Workflow für Anforderungen¶

Wenn ein Verbrauchender eine Anforderung für ein Organisations-Freigabeangebot vorlegt, die nicht genehmigt wurde, und das System einen Failover auf eine sekundäre Bereitstellung ausführt, kann der Replikatanbietende die Anfrage des Verbrauchenden nicht sehen. Dies liegt daran, dass Anforderungen an die Bereitstellung gebunden sind, in der die Anfragen ursprünglich gestellt wurden. Der Verbraucher muss das Freigabeangebot erneut anfordern.
Der Versuch, die Veröffentlichung des Freigabeangebots nach einem Failback in die primäre Region aufzuheben, schlägt in dem folgenden Szenario fehl:
- Ein Verbrauchender fordert ein Freigabeangebot an, das sich in einer primären Region und in deren Failover-Regionen befindet, und
- Der Verbrauchende fordert das Freigabeangebot erneut an, das in der sekundären Region genehmigt wurde.
Dieser Fehler tritt auf, weil die ursprüngliche ausstehende Anforderung erhalten bleibt. Um die Veröffentlichung erfolgreich aufzuheben, muss der Anbietende die ursprüngliche Anforderung ausdrücklich ablehnen und dann den Vorgang zum Aufheben der Veröffentlichung erneut durchführen.

Data Dictionary¶

Die empfohlenen Objekte sind nicht Teil des Failover-Replikationsprozesses. Folglich werden alle empfohlenen Objekte, die auf der primären Instanz ausgewählt wurden, nach einem Failover nicht in der sekundären Instanz übernommen. Der Anbietende muss diese Objekte nach einem Failover manuell zurücksetzen. Wenn der Anbietende die empfohlenen Objekte nicht zurücksetzt, würde dem Verbrauchenden ein veraltetes Data Dictionary angezeigt, selbst wenn er neue Tabellen hinzufügt. Das liegt daran, dass der Hintergrundjob dieses Freigabeangebot überspringt. Der Hintergrundjob verarbeitet dieses Freigabeangebot erst, nachdem die empfohlenen Objekte festgelegt wurden.
Wenn Änderungen an empfohlenen Objekten vorgenommen werden, während das System als Replikat läuft, werden diese Änderungen nach dem Failback nicht mit der ursprünglichen primären Instanz synchronisiert.

Data Preview¶

Die Data Preview-Informationen werden nicht in sekundäre Regionen repliziert. Daher werden Verbrauchenden nach einem Failover keine Data Preview-Dateien angezeigt. In der sekundären Region muss der Anbietende die Data Preview-Dateien neu generieren.
Ähnlich wie bei Data Dictionary werden alle Änderungen, die während eines Failover-Status an Data Preview vorgenommen werden, nach dem Failback nicht mit der ursprünglichen primären Instanz synchronisiert. Der Anbietende kann die Data Preview-Informationen nach einem Failback in der ursprünglichen primären Instanz zurücksetzen.

Organisationsprofile¶

Sowohl der primäre Anbietende als auch der sekundäre Anbietende müssen ein Profil verwenden, das das Freigabeangebot veröffentlichen kann.

Einschränkungen bei der Profilreplikation¶

Wenn Profile nicht von einer Failover-Gruppe repliziert werden, funktionieren die Freigabeangebote im sekundären Konto weiterhin, ohne dass Profile angehängt sind.
Wenn Profile nicht von einer Failover-Gruppe repliziert werden, bleiben die Profile des ursprünglichen primären Kontos nach einem Failover und einer Failback-Aktualisierung unverändert.
Die Profile des sekundären Kontos sind bis zum Failover schreibgeschützt. Nach dem Failover kann das neue primäre Konto Profile erstellen, ändern oder löschen.
Wenn das sekundäre Konto über ein lokales Profil verfügt, schlägt die erste Aktualisierung der Failover-Gruppe absichtlich fehl, um einen möglichen Datenverlust zu vermeiden. Befolgen Sie die Schritte in der Meldung über das Abfrageergebnis, um fortzufahren.
Profilgenehmigungsanforderungen werden nicht repliziert. Wenn im ursprünglichen primären Konto eine Genehmigungsanforderung aussteht, kann das neue primäre Konto nach dem Failover die Genehmigung erneut anfordern.

Einschränkungen für schreibgeschützte sekundäre Freigabeangebote¶

Sekundäre Freigabeangebote können nicht direkt geändert werden. Alle Schreiboperationen, wie z. B. ALTER und DROP, müssen für das primäre Freigabeangebot ausgeführt werden.