Failover von Kontoobjekten¶

Unter diesem Thema werden die Schritte beschrieben, die für ein Failover von replizierten Kontoobjekten über mehrere Konten in verschiedenen Regionen hinweg für die Notfallwiederherstellung (Disaster Recovery) erforderlich sind.

Voraussetzungen¶

Aktivieren Sie die Replikation für eine primäre Failover-Gruppe in den entsprechenden Konten.
Erstellen Sie mindestens eine sekundäre Failover-Gruppe (d. h. ein Replikat) der primären Failover-Gruppe in einem oder mehreren Konten, und aktualisieren (d. h. synchronisieren) Sie das Replikat regelmäßig mit den neuesten Aktualisierungen der Objekte in der Failover-Gruppe.

Eine Anleitung dazu finden Sie unter Replizieren von Datenbanken und Kontoobjekten über mehrere Konten hinweg.

Heraufstufen eines Zielkontos zur Verwendung als Quellkonto¶

Um ein Zielkonto zum Quellkonto heraufzustufen, müssen Sie sich bei dem Zielkonto anmelden, das als neues Quellkonto dienen soll, und den Befehl ALTER FAILOVER GROUP … PRIMARY ausführen.

Heraufstufen einer sekundären Failover-Gruppe zur primären Failover-Gruppe¶

Bemerkung

Das Beispiel in diesem Abschnitt muss von einer Rolle mit FAILOVER-Berechtigung ausgeführt werden.

Im folgenden Beispiel wird das Konto myaccount2 der aktuellen Organisation myorg heraufgestuft, um als Quellkonto zu dienen.

Melden Sie sich beim Zielkonto myaccount2 an.
Zeigen Sie die Failover-Gruppen im Konto an:
```
SHOW FAILOVER GROUPS;
```
Copy
Führen Sie die folgende Anweisung für jede sekundäre Failover-Gruppe aus, die Sie zur primären Failover-Gruppe heraufstufen möchten:
```
ALTER FAILOVER GROUP myfg PRIMARY;
```
Copy
Bemerkung

Während eines teilweisen Ausfalls in Ihrer Quellregion ist der Replikationsdienst möglicherweise weiterhin verfügbar und kann weiterhin die sekundären Failover-Gruppen in den Zielregionen aktualisieren.

Um die Datenintegrität sicherzustellen, verhindert Snowflake ein Failover, wenn gerade eine Aktualisierungsoperation ausgeführt wird. Das bedeutet, dass Sie eine sekundäre Failover-Gruppe nicht zur primären heraufstufen können, wenn sie gerade durch eine Replikationsoperation aktualisiert wird. Der Befehl ALTER FAILOVER GROUP … PRIMARY gibt in diesem Szenario einen Fehler zurück.

Beheben eines Fehlers der Failover-Anweisung aufgrund einer laufenden Aktualisierungsoperation¶

Wenn für die sekundäre Failover-Gruppe, die Sie heraufstufen möchten, gerade eine Aktualisierungsoperation ausgeführt wird, führt die Failover-Anweisung zu folgendem Fehler:

Replication group "<GROUP_NAME>" cannot currently be set as primary because it is being
refreshed. Either wait for the refresh to finish or cancel the refresh and try again.

Für ein erfolgreiches Failover müssen Sie die folgenden Schritte ausführen.

Entscheiden Sie sich für eine der folgenden Optionen:

Wichtig

Das Anhalten einer Aktualisierungsoperation in der Phase SECONDARY_DOWNLOADING_METADATA oder SECONDARY_DOWNLOADING_DATA kann zu einem inkonsistenten Zustand des Zielkontos führen. Weitere Informationen dazu finden Sie unter Aktuelle Phase einer laufenden Aktualisierungsoperation anzeigen.
1. Setzen Sie zukünftige Aktualisierungsoperationen für die Failover-Gruppe aus. Wenn eine Aktualisierungsoperation gerade ausgeführt wird, müssen Sie warten, bis sie abgeschlossen ist, bevor Sie ein Failover durchführen können:
  ALTER FAILOVER GROUP myfg SUSPEND;
  Copy
2. Setzen Sie zukünftige Aktualisierungsoperationen aus und brechen Sie eine geplante Aktualisierungsoperation ab, die gerade ausgeführt wird (falls es einen gibt).
  
  Informationen für den Fall, dass die laufende Aktualisierungsoperation manuell ausgelöst wurde, finden Sie unter Laufende Aktualisierungsoperation abbrechen, die nicht automatisch geplant wurde.
  ALTER FAILOVER GROUP myfg SUSPEND IMMEDIATE;
  Copy
  Bemerkung
  
  Möglicherweise kommt es zu einer leichten Verzögerung zwischen dem Zeitpunkt, an dem die Anweisung zurückkehrt, und dem Zeitpunkt, an dem der Abbruch der Aktualisierungsoperation abgeschlossen ist.

Stellen Sie sicher, dass gerade keine Aktualisierungsoperationen für die Failover-Gruppe myfg ausgeführt werden. Die folgende Abfrage darf keine Ergebnisse zurückgeben:

SELECT phase_name, start_time, job_uuid
  FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_HISTORY('myfg'))
  WHERE phase_name <> 'COMPLETED' and phase_name <> 'CANCELED';

Copy

Um abgebrochene Aktualisierungsoperationen für die Failover-Gruppe myfg anzuzeigen, können Sie die folgende Anweisung ausführen:

SELECT phase_name, start_time, job_uuid
  FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_HISTORY('myfg'))
  WHERE phase_name = 'CANCELED';

Copy

Jetzt können Sie die sekundäre Failover-Gruppe myfg zur primären Failover-Gruppe heraufstufen:
```
ALTER FAILOVER GROUP myfg PRIMARY;
```
Copy

Geplante Replikation in Zielkonten fortsetzen¶

Beim Failover werden die geplanten Aktualisierungen auf allen sekundären Failover-Gruppen angehalten. ALTER FAILOVER GROUP … RESUME muss in jedem Zielkonto mit einer sekundären Failover-Gruppe ausgeführt werden, damit die automatischen Aktualisierungen fortgesetzt werden.

ALTER FAILOVER GROUP myfg RESUME;

Copy

Aktuelle Phase einer laufenden Aktualisierungsoperation anzeigen¶

Eine Aktualisierungsoperation kann in den meisten Phasen der Aktualisierungsoperation sicher abgebrochen werden. Wenn Sie jedoch eine Aktualisierungsoperation in der Phase SECONDARY_DOWNLOADING_METADATA oder SECONDARY_DOWNLOADING_DATA abbrechen, kann dies zu einem inkonsistenten Status des Zielkontos führen. Wenn die Aktualisierungsoperation eine dieser Phasen gestartet hat, wird sie unabhängig von der Verfügbarkeit des Quellkontos abgeschlossen. Wenn Sie die Phase vor dem Failover abschließen, wird sichergestellt, dass sich die Replikate in einem konsistenten Zustand befinden. Nachdem die Replikate in einem konsistenten Zustand sind, können Sie Ihre Datenaufnahme- und Transformationspipelines fortsetzen oder wiederholen, um die Replikate auf den aktuellen Stand zu bringen.

Um die aktuelle Phase einer laufenden Aktualisierungsoperation für eine Failover-Gruppe anzuzeigen, verwenden Sie die Information Schema-Tabellenfunktion REPLICATION_GROUP_REFRESH_PROGRESS, REPLICATION_GROUP_REFRESH_PROGRESS_BY_JOB.

Um beispielsweise die aktuelle Phase einer laufenden Aktualisierungsoperation für die Failover-Gruppe myfg anzuzeigen, führen Sie die folgende Anweisung aus:

SELECT phase_name, start_time, end_time
  FROM TABLE(
    INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_PROGRESS('myfg')
  );

Copy

Eine Liste der Phasen von Aktualisierungsoperationen finden Sie in den Nutzungshinweisen der Funktion.

Laufende Aktualisierungsoperation abbrechen, die nicht automatisch geplant wurde¶

Um eine laufende Aktualisierungsoperation abzubrechen, die nicht automatisch durch einen Replikationsplan ausgelöst wurde, müssen Sie die Funktion SYSTEM$CANCEL_QUERY verwenden:

Suchen Sie die Abfrage-ID oder die JOB_UUID für die Ausführung von Aktualisierungsoperationen mit einer der folgenden Optionen:
1. Suchen Sie die Abfrage-IDs für alle laufenden Aktualisierungsoperationen:
  SELECT query_id, query_text FROM TABLE(INFORMATION_SCHEMA.QUERY_HISTORY()) WHERE query_type = 'REFRESH REPLICATION GROUP' AND execution_status = 'RUNNING' ORDER BY start_time;
  Copy
  Verwenden Sie die Spalte QUERY_TEXT, um die QUERY_ID für Aktualisierungsoperationen von Failover-Gruppen in der Liste zu identifizieren.
2. Suchen der JOB_UUID einer laufenden Aktualisierungsoperation für eine bestimmte Failover-Gruppe myfg:
  SELECT phase_name, start_time, job_uuid FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_HISTORY('myfg')) WHERE phase_name <> 'COMPLETED' and phase_name <> 'CANCELED';
  Copy
Brechen Sie die Aktualisierungsoperation mit der Funktion SYSTEM$CANCEL_QUERY und der QUERY_ID bzw. JOB_UUID ab:
```
SELECT SYSTEM$CANCEL_QUERY('<QUERY_ID | JOB_UUID>');
```
Copy
Folgende Ausgabe wird zurückgegeben:
```
query [<QUERY_ID>] terminated.
```
Nachdem Sie die laufende Aktualisierungsoperation abgebrochen haben, fahren Sie mit den nächsten Schritten fort.

Aktive Kanäle für Snowpipe Streaming im neu heraufgestuften Quellkonto wieder öffnen¶

Tabellen in einer Primärdatenbank, die von Snowpipe Streaming befüllt werden, werden per Snowpipe Streaming-Replikation in Sekundärdatenbanken repliziert. Öffnen Sie nach dem Failover aktive Snowpipe Streaming-Kanäle für Tabellen erneut, und fügen Sie alle fehlenden Datenzeilen für die Kanäle neu ein:

Öffnen Sie die aktiven Kanäle für die Tabelle erneut, indem Sie die API openChannel aufrufen.
So rufen Sie Offset-Token ab:
1. Rufen Sie die API getLatestCommittedOffsetToken auf oder
2. Führen Sie den Befehl SHOW CHANNELS aus, um eine Liste der aktiven Kanäle der Tabelle abzurufen.
Fügen Sie die Datenzeilen für den Kanal aus den abgerufenen Offset-Tokens wieder ein.

Snowpipe Streaming und der Kafka-Konnektor¶

Wenn Sie den Kafka-Konnektor und Snowpipe Streaming verwenden, führen Sie nach dem Failover die folgenden Schritte aus:

Aktualisieren Sie die Konfiguration des Kafka-Konnektors, sodass dieser auf das neu heraufgestufte Quellkonto verweist.
Führen Sie den Befehl SHOW CHANNELS aus, um die Liste der aktiven Kanäle und der Offset-Token abzurufen. Jeder Kanal gehört zu einer einzelnen Partition im Kafka-Thema.
Setzen Sie die Offsets im Kafka-Thema für jede dieser Partitionen (Kanäle) manuell zurück.
Starten Sie den Kafka-Konnektor neu.

Weitere Informationen dazu finden Sie unter: