Einführung in Geschäftskontinuität und Notfallwiederherstellung

Unter diesem Thema werden die wichtigsten Anwendungsfälle für die Replikation und das Failover von Daten auf ein Snowflake-Konto in einer anderen Region oder sogar auf einer anderen Cloudplattform beschrieben.

Die Snowflake-Funktionalität für Replikation und Failover/Failback weist die folgenden Features auf:

Datenbankreplikation

Die Datenbankreplikation ermöglicht das Speichern von Nur-Lese-Replikaten einer Primärdatenbank in anderen Snowflake-Konten. Diese Konten, die in derselben Organisation gruppiert sein müssen, können sich in verschiedenen Regionen oder auf verschiedenen Cloudplattformen befinden. Bei der Aktualisierung jedes Replikats (Sekundärdatenbank) werden die Datenbankobjekte und gespeicherten Daten mit ihrer Primärdatenbank synchronisiert.

Datenbank-Failover/Failback

Durch das Datenbank-Failover/Failback wird ein Replikat zur Primärdatenbank hochgestuft. Zu diesem Zeitpunkt wird die frühere Primärdatenbank zu einer Sekundärdatenbank mit Lesezugriff, und das frühere Replikat wird zur Primärdatenbank mit Lesezugriff.

Clientumleitung

Eine Clientumleitung stellt eine Verbindungs-URL bereit, die von Snowflake-Clients zur Verbindung mit Snowflake verwendet werden kann. Die Verbindungs-URL kann bei Bedarf auf ein anderes Snowflake-Konto umgeleitet werden.

Diese einzelnen Funktionen sind so konzipiert, dass sie zusammengenommen eine Reihe verschiedener grundlegender Geschäftsszenarios unterstützen, darunter:

  • Wiederherstellung nach dem Ausfall einer Cloudplattformregion, wobei Schreibvorgänge in der Datenbank Vorrang vor Lesevorgängen haben.

  • Wiederherstellung nach dem Ausfall einer Cloudplattformregion, wobei Lesevorgänge in der Datenbank Vorrang vor Schreibvorgängen haben.

  • Wiederherstellung nach dem Ausfall einer Cloudplattformregion, wobei Lese- und Schreibvorgänge in der Datenbank gleichermaßen beachtet werden.

  • Migrieren der Datenbanken von einer Cloudplattform oder Region zu einer anderen.

Darüber hinaus ermöglichen Snowflake Secure Data Sharing und Datenbankreplikation die sichere gemeinsame Nutzung von Daten über Regionen und Cloudplattformen hinweg.

Unter diesem Thema:

Geschäftskontinuität und Notfallwiederherstellung

Im Falle eines massiven Ausfalls (aufgrund eines Netzwerkproblems, eines Softwarefehlers usw.), der die Clouddienste in einer bestimmten Region unterbricht, ist der Zugriff auf Snowflake unterbrochen, bis die Ursache des Ausfalls behoben und die Services wiederhergestellt wurden. Um die kontinuierliche Verfügbarkeit und Datendauerhaftigkeit in einem solchen Szenario sicherzustellen, können Sie kritische Datenbanken auf ein anderes Snowflake-Konto Ihrer Organisation in einer anderen Region replizieren.

Bei der asynchronen Replikation bleiben die sekundären Replikate in der Regel hinter der Primärdatenbank zurück, je nach der von Ihnen konfigurierten Replikationshäufigkeit. Wenn Sie sich beispielsweise dafür entscheiden, eine Primärdatenbank alle 30 Minuten zu replizieren, liegt die sekundäre Replikation während eines Ausfalls höchstens 30 Minuten hinter der primären zurück.

Je nach den Anforderungen Ihres Unternehmens haben Sie folgende Optionen:

  • Datenbank-Lesevorgänge zuerst wiederherstellen, damit Clientanwendungen Daten lesen können, die 30 Minuten veraltet sind.

  • Datenbank-Schreibvorgänge zuerst wiederherstellen, um die Daten der letzten 30 Minuten auf der neuen Primärdatenbank abzustimmen, bevor Sie die Lesevorgänge von Clientanwendungen öffnen.

  • Lese- und Schreibvorgänge der Datenbank gleichzeitig wiederherstellen, d. h. Lesezugriffe der Clientanwendungen auf Daten, die 30 Minuten veraltet sind, werden geöffnet, während zugleich die letzten 30 Minuten an Daten auf der neuen Primärdatenbank abgestimmt werden.

Um Lese- und Schreibvorgänge der Datenbank gleichermaßen zu priorisieren, führen Sie die Schritte aus einem der folgenden Szenarios aus. Wenn es in einer Region zu einem Ausfall kommt, können Sie wählen, ob Sie das Failover Ihrer kritischen Datenbanken und der Snowflake-Clientverbindungen gleichzeitig ausführen möchten.

Datenbank-Lesevorgänge vor Schreibvorgängen

Wenn ein Ausfall in einer Region zu einem vollständigen oder teilweisen Verlust der Snowflake-Verfügbarkeit führt, können Sie über diesen Pfad Snowflake-Clients zunächst auf schreibgeschützte Replikate kritischer Datenbanken umleiten, um die Ausfallzeit zu minimieren. Bei kurzfristigen Ausfällen ist es oft wünschenswert, im Nur-Lese-Modus zu arbeiten.

Ein längerfristiger Ausfall in Verbindung mit dem Bedarf an aktuellen Daten erfordert den Schreib-Lese-Modus.

Die Schritte für diesen Pfad sind wie folgt.

Normaler Status: Region ist betriebsbereit

  1. Datenbankreplikation: Replizieren Sie kritische Datenbanken auf ein oder mehrere Snowflake-Konten, die sich in anderen Regionen als das Konto befinden, in dem die primären (Quell-)Datenbanken gespeichert sind. Aktualisieren Sie die Datenbankobjekte und gespeicherten Daten regelmäßig.

Ausfall der Region

  1. Clientumleitung: Lassen Sie die von den Clients verwendete Verbindungs-URL auf ein Snowflake-Konto verweisen, in dem Ihre schreibgeschützten sekundären Replikatdatenbanken gespeichert sind.

  2. Datenbank-Failover (bei Bedarf): Im Falle eines längerfristigen Ausfalls können Sie die Sekundärdatenbanken in dem Snowflake-Konto, auf das Ihre Verbindungs-URL verweist, als Primärdatenbanken mit Lese-Schreib-Zugriff verwenden.

Normaler Status: Ausfall ist behoben

  1. Datenbankreplikation: Aktualisieren Sie die Datenbanken im Snowflake-Konto in der Region, in der der Ausfall aufgetreten ist.

  2. Datenbank-Failback: Stellen Sie die Datenbanken in dem Snowflake-Konto, in dem der Ausfall aufgetreten ist, wieder als Primärdatenbanken zur Verfügung.

  3. Clientumleitung: Lassen Sie die von Clients verwendete Verbindungs-URL wieder auf das Snowflake-Konto in der Region verweisen, in der der Ausfall aufgetreten ist.

Datenbank-Schreibvorgänge vor Lesevorgängen

Wenn ein Ausfall in einer Region zu einem vollständigen oder teilweisen Verlust der Snowflake-Verfügbarkeit führt, können Sie über diesen Pfad kritische Datenbanken wiederherstellen und zunächst mit der Verarbeitung von Daten fortfahren. Diese Option ist von Kontoadministratoren zu bevorzugen, die zuerst das Failover ihrer Datenbanken und ETL-Prozesse (Extrahieren, Transformieren, Laden) verarbeiten möchten und die Snowflake-Clients erst dann umleiten möchten, wenn die Daten aktuell sind.

Die Schritte für diesen Pfad sind wie folgt.

Normaler Status: Region ist betriebsbereit

  1. Datenbankreplikation: Replizieren Sie kritische Datenbanken auf ein oder mehrere Snowflake-Konten, die sich in anderen Regionen als das Konto befinden, in dem die primären (Quell-)Datenbanken gespeichert sind. Aktualisieren Sie die Datenbankobjekte und gespeicherten Daten regelmäßig.

Ausfall der Region

  1. Datenbank-Failover: Replikate kritischer Datenbanken in einer anderen Region werden als zu Primärdatenbanken heraufgestuft, was das Schreiben auf diese Datenbanken ermöglicht. Sobald die Datenbanken beschreibbar sind, können Sie Ihre ETL-Prozesse verwenden, um Schreibvorgänge zu priorisieren und Daten abzustimmen.

  2. Clientumleitung (bei Bedarf): Lassen Sie die von den Clients verwendete Verbindungs-URL auf das Snowflake-Konto verweisen, in dem die neuen Primärdatenbanken gespeichert sind.

Normaler Status: Ausfall ist behoben

  1. Datenbankreplikation: Aktualisieren Sie die Datenbanken im Snowflake-Konto in der Region, in der der Ausfall aufgetreten ist.

  2. Datenbank-Failback: Stellen Sie die Datenbanken in dem Snowflake-Konto, in dem der Ausfall aufgetreten ist, wieder als Primärdatenbanken zur Verfügung.

  3. Clientumleitung: Lassen Sie die von Clients verwendete Verbindungs-URL wieder auf das Snowflake-Konto in der Region verweisen, in der der Ausfall aufgetreten ist.

Abläufe für Geschäftskontinuität und Notfallwiederherstellung

Die Abbildungen in diesem Abschnitt zeigen die Abläufe für Geschäftskontinuität und Notfallwiederherstellung.

Ablauf für Datenbanken

  1. Die folgende Abbildung zeigt zwei Konten derselben Organisation, jedoch in unterschiedlichen Regionen (Region A und Region B). In einem Konto wurde eine lokale Datenbank zur primären Datenbank heraufgestuft. Die Replikation wurde für das andere Konto aktiviert und ermöglicht das Speichern eines Replikats der primären Datenbank (d. h. eine sekundäre Datenbank):

    Initial state of database replication
  2. Die folgende Abbildung zeigt eine sekundäre Datenbank, die in einem Konto in Region B erstellt wurde. Der grüne Pfeil zeigt eine laufende Datenaktualisierungsoperation von der Primärdatenbank zur Sekundärdatenbank an:

    Data replication operation in progress
  3. Die folgende Abbildung zeigt ein Failover-Szenario: Ein Dienstausfall in Region A, in dem sich das Konto befindet, das die Primärdatenbank enthält. Die Sekundärdatenbank (in Region B) wurde heraufgestuft, um als Primärdatenbank zu dienen. Gleichzeitig wurde die frühere Primärdatenbank zu einer schreibgeschützten Sekundärdatenbank:

    Database failover

    Die Schritte zum Failover einer Datenbank sind unter Failover von Datenbanken über mehrere Konten beschrieben.

  4. Die folgende Abbildung zeigt, dass der Serviceausfall in Region A behoben wurde. Eine Datenbankaktualisierungsoperation wird von der Primärdatenbank (in Region B) zur Sekundärdatenbank (in Region A) ausgeführt:

    Database failover
  5. Die letzte Abbildung zeigt die Operationen, die auf ihre ursprüngliche Konfiguration (d. h. Failback) zurückgesetzt wurden. Die sekundäre Datenbank (in Region A) wurde heraufgestuft, um erneut als primäre Datenbank für den normalen Geschäftsbetrieb zu dienen. Gleichzeitig wurde die bisherige Primärdatenbank (in Region B) zu einer schreibgeschützten Sekundärdatenbank:

    Database failover

Ablauf für Verbindungen

  1. Die folgenden Abbildungen zeigen zwei Konten derselben Organisation, aber in unterschiedlichen Regionen (Region A und Region B) auf derselben oder auf unterschiedlichen Cloudplattformen. Die Verbindungs-URL für Clientverbindungen ist für ein Konto in Region A konfiguriert:

    Normal client connections
  2. Die folgende Abbildung zeigt einen Dienstausfall in Region A, der zu fehlgeschlagenen Clientverbindungen führt:

    Failed client connections
  3. Die folgende Abbildung zeigt, dass die Verbindungs-URL für Clientverbindungen jetzt für ein Konto in Region B konfiguriert ist. Clients, die sich mit der Verbindungs-URL verbinden, verbinden sich jetzt mit dem Konto in Region B.

    Beachten Sie, dass die Clientumleitung ein manueller Prozess ist. Eine Anleitung dazu finden Sie unter Umleiten von Clientverbindungen.

    Redirected client connections

Kontenmigration

Die Kontenmigration ist der einmalige Prozess der Migration (oder Übertragung) der Snowflake-Objekte und Ihrer gespeicherten Daten in ein Konto in einer anderen Region oder auf einer anderen Cloudplattform. Typische Gründe für die Migration Ihres Kontos sind eine größere Nähe zu Ihrer Benutzerbasis oder die Präferenz für eine andere Cloudplattform auf der Grundlage Ihrer Unternehmensstrategie oder die gemeinsame Nutzung mit anderen Cloudressourcen (z. B. einem Data Lake).

Derzeit ist die Unterstützung für die Replikation von Snowflake-Objekten auf Datenbanken beschränkt, die als Container für Objekte dienen, die Daten speichern (z. B. Tabellen und Ansichten, einschließlich materialisierter Ansichten). Unter Replizierte Datenbankobjekte finden Sie eine vollständige Liste der replizierten Objekte. Nutzen Sie den Snowflake-Support, um Kontoobjekte (z. B. Benutzer und Rollen) sowie andere Snowflake-Objekte auf das neue Konto zu replizieren.

Bemerkung

Datenbank-Failover/Failback erfordert Business Critical (oder höher). Snowflake kann für eine einmalige Kontenmigration vorübergehend auf diese Anforderung verzichten.