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.

For information about the purpose of the failover mechanism and when to use it, see Einführung in Geschäftskontinuität und Notfallwiederherstellung.

Prerequisites

  1. Enable replication in a set of accounts within the same organization, across multiple regions in one cloud service provider or across different cloud service providers.

  2. Create a primary failover group that defines the kinds of objects to replicate, and specifies the target accounts to which to replicate. You can optionally divide the replicated objects across multiple failover groups, for example if some databases should be replicated more frequently than others.

  3. Create at least one secondary failover group (replica) of each primary failover group in one or more secondary accounts.

  4. Refresh (synchronize) each replica with the latest updates to the objects in the failover group. Perform an initial refresh, and set up a schedule to regularly bring the latest changes to each secondary account.

For instructions, see Replizieren von Kontoobjekten und Datenbanken.

Heraufstufen eines Zielkontos zum Quellkonto

Sie können ein Zielkonto zum Quellkonto machen (Failover), indem Sie Snowsight oder SQL verwenden.

For more information about the kinds of objects you can specify in a failover group, see Replikationsgruppen und Failover-Gruppen.

Promote a target account to serve as the source account using Snowsight

Bemerkung

Only account administrators can edit a replication or failover group using Snowsight (see Einschränkungen bei der Verwendung von Snowsight für die Replikationskonfiguration).

For the most consistent and reliable failover experience, select all the applicable failover groups and connections and promote them all at the same time. We refer to this operation as a bulk failover.

To promote a target account to serve as the source account using Snowsight, follow these steps:

  1. Sign in to Snowsight. Make sure to sign in using the target account.

  2. Wählen Sie im Navigationsmenü die Option Admin » Accounts aus.

  3. Select Replication, then select Initiate failover. Doing so brings up a dialog where you make the remaining choices.

  4. Select any failover groups to promote. After the failover, the objects specified in those failover groups become writable on the newly promoted primary account. Those objects become read-only on the account that formerly was the primary and is now a secondary account.

  5. Select Next.

  6. Select any connections to promote. After the failover, those connections connect to the account that you’re promoting to be the new primary account.

  7. Select Next.

  8. Select Fail over in the confirmation window.

  9. If any refresh operations are in progress for the failover groups you selected, you can wait for those refreshes to complete, or choose an alternative approach if your failover is urgent and should take priority.

    The default action is to wait for the refreshes to complete. That way, the primary and secondary systems are all in a consistent state when the bulk failover runs. Snowflake uses your currently selected warehouse to poll the status of the ongoing refreshes. If you don’t have a selected warehouse, you select one now using the Select warehouse option.

    Or, you can proceed with the failover immediately by selecting Show advanced options.

    • To fail over only the failover groups that aren’t currently being refreshed, select Exit with current progress. In that case, you perform additional refreshes later for the groups that were skipped during the bulk failover.

    • To cancel the refresh operations and continue the failover, select Cancel refreshes and force failover. In that case, you might need to clean up any inconsistencies on the secondary system from the interrupted refreshes.

If the failover operation didn’t complete for all failover groups, you can perform another bulk failover. Or you can fail over the remaining failover groups one at a time, using the procedure in Promote a single failover group to serve as the primary using Snowsight.

Promote a single failover group to serve as the primary using Snowsight

Bemerkung

Only account administrators can edit a replication or failover group using Snowsight (see Einschränkungen bei der Verwendung von Snowsight für die Replikationskonfiguration).

To promote a single failover group to be the primary using Snowsight, follow these steps:

  1. Sign in to Snowsight. Make sure to sign in using the target account.

  2. Wählen Sie im Navigationsmenü die Option Admin » Accounts aus.

  3. Wählen Sie Replication und dann Groups aus.

  4. Suchen Sie die Failover-Gruppe, die Sie verschieben möchten, und wählen Sie das Menü More () in der letzten Spalte der Zeile.

  5. Wählen Sie Fail over, und wählen Sie dann im Bestätigungsfenster Fail over.

Tipp

You typically use this procedure if you encounter a problem failing over one group, and you need to retry the failover only for that group. To promote an entire account to be the primary, select multiple failover groups and connections and perform a bulk failover. For more information, see Promote a target account to serve as the source account using Snowsight.

Heraufstufen eines Zielkontos zum Quellkonto mit SQL

To promote a target account to serve as the source account using SQL, you sign in to the target account and execute the ALTER FAILOVER GROUP … PRIMARY command.

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.

  1. Melden Sie sich beim Zielkonto myaccount2 an.

  2. Zeigen Sie die Failover-Gruppen im Konto an:

    SHOW FAILOVER GROUPS;
    
    Copy
  3. 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.

  1. 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.

  2. 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
  3. 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, REPLICATION_GROUP_REFRESH_PROGRESS_ALL.

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:

  1. 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
  2. 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.
    
  3. 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:

  1. Öffnen Sie die aktiven Kanäle für die Tabelle erneut, indem Sie die API openChannel aufrufen.

  2. 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.

  3. Fügen Sie die Datenzeilen für den Kanal aus den abgerufenen Offset-Tokens wieder ein.

Bemerkung

Diese Schritte gelten nur für Snowpipe Streaming mit dem Snowflake Ingest SDK; sie gelten nicht für Snowpipe Streaming mit dem Kafka Connector. Führen Sie die folgenden Schritte aus, um den Kafka Connector nach dem Failover neu zu starten.

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:

  1. Aktualisieren Sie die Konfiguration des Kafka-Konnektors, sodass dieser auf das neu heraufgestufte Quellkonto verweist.

  2. 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.

  3. Setzen Sie die Offsets im Kafka-Thema für jede dieser Partitionen (Kanäle) manuell zurück.

  4. Starten Sie den Kafka-Konnektor neu.

For more information, see: