ALTER FAILOVER GROUP¶

Syntax¶

Quellkonto

ALTER FAILOVER GROUP [ IF EXISTS ] <name> RENAME TO <new_name>

ALTER FAILOVER GROUP [ IF EXISTS ] <name> SET
  [ OBJECT_TYPES = <object_type> [ , <object_type> , ... ] ]
  [ ALLOWED_DATABASES = <db_name> [ , <db_name> , ... ] ]
  [ ALLOWED_SHARES = <share_name> [ , <share_name> , ... ] ]

ALTER FAILOVER GROUP [ IF EXISTS ] <name> SET
  OBJECT_TYPES = INTEGRATIONS [ , <object_type> , ... ]
  ALLOWED_INTEGRATION_TYPES = <integration_type_name> [ , <integration_type_name> ... ]

ALTER FAILOVER GROUP [ IF EXISTS ] <name> SET
  REPLICATION_SCHEDULE = '{ <num> MINUTE | USING CRON <expr> <time_zone> }'

ALTER FAILOVER GROUP [ IF EXISTS ] <name> SET TAG <tag_name> = '<tag_value>' [ , <tag_name> = '<tag_value>' ... ]

ALTER FAILOVER GROUP [ IF EXISTS ] <name>
  ADD <db_name> [ , <db_name> ,  ... ] TO ALLOWED_DATABASES

ALTER FAILOVER GROUP [ IF EXISTS ] <name>
  MOVE DATABASES <db_name> [ , <db_name> ,  ... ] TO FAILOVER GROUP <move_to_fg_name>

ALTER FAILOVER GROUP [ IF EXISTS ] <name>
  REMOVE <db_name> [ , <db_name> ,  ... ] FROM ALLOWED_DATABASES

ALTER FAILOVER GROUP [ IF EXISTS ] <name>
  ADD <share_name> [ , <share_name> ,  ... ] TO ALLOWED_SHARES

ALTER FAILOVER GROUP [ IF EXISTS ] <name>
  MOVE SHARES <share_name> [ , <share_name> ,  ... ] TO FAILOVER GROUP <move_to_fg_name>

ALTER FAILOVER GROUP [ IF EXISTS ] <name>
  REMOVE <share_name> [ , <share_name> ,  ... ] FROM ALLOWED_SHARES

ALTER FAILOVER GROUP [ IF EXISTS ] <name>
  ADD <org_name>.<target_account_name> [ , <org_name>.<target_account_name> ,  ... ] TO ALLOWED_ACCOUNTS
  [ IGNORE EDITION CHECK ]

ALTER FAILOVER GROUP [ IF EXISTS ] <name>
  REMOVE <org_name>.<target_account_name> [ , <org_name>.<target_account_name> ,  ... ] FROM ALLOWED_ACCOUNTS

Zielkonto

ALTER FAILOVER GROUP [ IF EXISTS ] <name> REFRESH

ALTER FAILOVER GROUP [ IF EXISTS ] <name> PRIMARY

ALTER FAILOVER GROUP [ IF EXISTS ] <name> SUSPEND [ IMMEDIATE ]

ALTER FAILOVER GROUP [ IF EXISTS ] <name> RESUME

Parameter¶

Quellkonto

name

Gibt den Bezeichner der Failover-Gruppe an.

RENAME TO new_name

new_name

Gibt den neuen Bezeichner der Failover-Gruppe an. Der neue Bezeichner kann nicht verwendet werden, wenn der Bezeichner bereits für ein andere Replikations- oder Failover-Gruppe verwendet wird.

Weitere Details dazu finden Sie unter Anforderungen an Bezeichner.

SET ...

Gibt Eigenschaften an, die für die Failover-Gruppe festgelegt werden sollen (getrennt durch Leerzeichen, Kommas oder Neue-Zeile-Zeichen):

OBJECT_TYPES = object_type [ , object_type , ... ]

Setzt die Liste von Objekttypen zurück, für die Sie Replikation und Failover vom Quellkonto zu einem oder mehreren Zielkonten aktivieren.

Bemerkung

Datenbank- und Freigabeobjekte:

• Wenn DATABASES oder SHARES in der Liste OBJECT_TYPES enthalten sind und in der Liste OBJECT_TYPES verbleiben, nachdem die Liste zurückgesetzt wurde, bleibt die Liste der jeweils zulässigen Objekte (ALLOWED_DATABASES oder ALLOWED_SHARES) unverändert.

• Wenn die Liste OBJECT_TYPES zurückgesetzt wird, um DATABASES hinzuzufügen oder zu entfernen, wird die Liste ALLOWED_DATABASES auf NULL gesetzt.

• Wenn die Liste OBJECT_TYPES zurückgesetzt wird, um SHARES hinzuzufügen oder zu entfernen, wird die Liste ALLOWED_SHARES auf NULL gesetzt.

• Verwenden Sie die Klauseln ADD, MOVE und REMOVE, um die Liste der zulässigen Datenbank- oder Freigabeobjekte zu ändern.

Die folgenden Objekttypen werden unterstützt:

ACCOUNT PARAMETERS:

Alle Parameter auf Kontoebene. Dazu gehören Kontoparameter und Parameter, die für Ihr Konto eingestellt werden können.

DATABASES:

Fügen Sie Datenbankobjekte zur Liste der Objekttypen hinzu. Wenn in der Liste der angegebenen Objekttypen bereits Datenbankobjekte enthalten waren, bleibt die Liste ALLOWED_DATABASES unverändert. Um die Liste der Datenbanken zu ändern, verwenden Sie die ADD-, MOVE- oder REMOVE-Klausel.

INTEGRATIONS:

Derzeit werden nur Sicherheitsintegrationen, API-Integrationen, Speicherintegrationen, Integrationen für den externen Zugriff [2] sowie bestimmte Typen von Benachrichtigungsintegrationen unterstützt. Weitere Details dazu finden Sie unter Integrationsreplikation.

Wenn Integrationsobjekte in der Liste der angegebenen Objekttypen enthalten sind, muss der Parameter ALLOWED_INTEGRATION_TYPES gesetzt werden.

NETWORK POLICIES:

Alle Netzwerkrichtlinien im Quellkonto.

RESOURCE MONITORS:

Alle Ressourcenmonitore im Quellkonto.

ROLES:

Alle Rollen im Quellkonto. Das Replizieren von Rollen schließt implizit alle Berechtigungen für Objekttypen ein, die in der Replikationsgruppe enthalten sind. Wenn beispielsweise ROLES der einzige Objekttyp ist, der repliziert wird, werden nur Rollenhierarchien (d. h. Rollen, die anderen Rollen zugewiesen werden) in Zielkonten repliziert. Wenn der Objekttyp USERS ebenfalls enthalten ist, werden auch die Rollenzuweisungen an die Benutzer repliziert.

SHARES:

Fügen Sie Freigabeobjekte zur Liste der Objekttypen hinzu. Wenn in der Liste der freigegebenen Objekttypen bereits Freigabeobjekte enthalten waren, bleibt die Liste ALLOWED_SHARES unverändert. Um die Liste der Freigaben zu ändern, verwenden Sie die ADD-, MOVE- oder REMOVE-Klausel.

USERS:

Alle Benutzer des Quellkontos.

WAREHOUSES:

Alle Warehouses des Quellkontos.

ALLOWED_DATABASES = db_name [ , db_name , ... ]

Gibt die Datenbank oder die Liste der Datenbanken an, für die Sie Replikation und Failover vom Quellkonto zum Zielkonto aktivieren. Damit Sie diesen Parameter einstellen können, muss die OBJECT_TYPES-Liste DATABASES enthalten.

db_name

Gibt den Bezeichner der Datenbank an.

ALLOWED_SHARES = share_name [ , share_name , ... ]

Gibt die Freigabe oder die Liste der Freigaben an, für die Sie Replikation und Failover vom Quellkonto zum Zielkonto aktivieren. Damit Sie diesen Parameter einstellen können, muss die OBJECT_TYPES-Liste SHARES enthalten.

share_name

Gibt den Bezeichner der Freigabe an.

Bemerkung

Wenn die Liste ALLOWED_DATABASES oder ALLOWED_SHARES geändert wurden, werden alle Objekte, die sich zuvor in der Liste befanden und entfernt wurden, bei der nächsten Aktualisierungsoperation in jedem Zielkonto mit einer verknüpften sekundären Failover-Gruppe gelöscht.

ALLOWED_INTEGRATION_TYPES = integration_type_name [ , integration_type_name , ... ]

Typ(en) von Integrationen, für die Sie Replikation und Failover vom Quellkonto zum Zielkonto aktivieren.

Die Liste OBJECT_TYPES muss INTEGRATIONS enthalten, damit dieser Parameter gesetzt werden kann.

Die folgenden Integrationstypen werden unterstützt:

SECURITY INTEGRATIONS:

Gibt die Sicherheitsintegrationen an.

Die Liste OBJECT_TYPES muss ROLES enthalten, damit dieser Parameter gesetzt werden kann.

API INTEGRATIONS:

Gibt die API-Integrationen an.

Für die Replikation von API-Integrationen sind zusätzliche Einstellungen erforderlich, nachdem die API-Integration in das Zielkonto repliziert wurde. Weitere Informationen dazu finden Sie unter Aktualisieren des Remotedienstes für API-Integrationen.

STORAGE INTEGRATIONS:

Gibt Speicherintegrationen an.

EXTERNAL ACCESS INTEGRATIONS:

Gibt Integrationen für den externen Zugriff an.

Weitere Informationen dazu finden Sie unter Replikation von gespeicherten Prozeduren und benutzerdefinierten Funktionen (UDFs).

Bemerkung

Der externe Zugriff wird in der Azure Gov-Region nicht unterstützt.

NOTIFICATION INTEGRATIONS:

Gibt die Benachrichtigungsintegrationen an.

Es werden nur bestimmte Typen von Benachrichtigungsintegrationen repliziert. Weitere Details dazu finden Sie unter Integrationsreplikation.

REPLICATION_SCHEDULE ...

Gibt den Zeitplan für das Aktualisieren der sekundären Failover-Gruppen an:

• USING CRON expr time_zone

  Gibt einen Cron-Ausdruck und eine Zeitzone für das Aktualisieren der sekundären Gruppe an. Unterstützt eine Teilmenge der Standardsyntax des Cron-Dienstprogramms.

  Eine Liste der Zeitzonen finden Sie unter List of tz database time zones (Liste der Zeitzonen aus der IANA-Zeitzonen-Datenbank) (Wikipedia).

  Der Cron-Ausdruck besteht aus folgenden Feldern:

  # __________ minute (0-59)
  # | ________ hour (0-23)
  # | | ______ day of month (1-31, or L)
  # | | | ____ month (1-12, JAN-DEC)
  # | | | | __ day of week (0-6, SUN-SAT, or L)
  # | | | | |
  # | | | | |
    * * * * *
  

  Folgende Sonderzeichen werden unterstützt:

  *

  Platzhalter. Gibt jedes vorkommende Feld an.

  L

  Steht für „last“ (letzte). Bei Verwendung im Feld Wochentag können Sie Konstrukte wie „den letzten Freitag“ („5L“) eines bestimmten Monats angeben. Im Feld Tag des Monats wird der letzte Tag des Monats angegeben.

  /n

  Gibt die n-te Instanz einer bestimmten Zeiteinheit an. Jeder Zeitanteil wird unabhängig berechnet. Wenn beispielsweise im Monatsfeld 4/3 angegeben ist, ist die Aktualisierung für April, Juli und Oktober geplant (d. h. alle 3 Monate, beginnend mit dem 4. Monat des Jahres). In den Folgejahren wird derselbe Zeitplan beibehalten. Das heißt, die Aktualisierung ist nicht für eine Ausführung im Januar (3 Monate nach der Oktober-Ausführung) geplant.

  Bemerkung

  • Der Cron-Ausdruck wird derzeit nur für die angegebene Zeitzone ausgewertet. Durch Ändern des TIMEZONE-Parameterwerts für das Konto (oder Festlegen des Werts auf Benutzer- oder Sitzungsebene) wird die Zeitzone für das Aktualisieren nicht geändert.

  • Der Cron-Ausdruck definiert alle gültigen Ausführungszeiten für das Aktualisieren. Snowflake versucht, die sekundären Gruppen auf Basis dieses Zeitplans zu aktualisieren. Eine gültige Laufzeit wird jedoch übersprungen, wenn eine vorherige Laufzeit nicht vor dem Start der nächsten gültigen Laufzeit abgeschlossen wurde.

  • Wenn sowohl ein bestimmter Tag des Monats als auch ein bestimmter Wochentag im Cron-Ausdruck enthalten sind, wird die Aktualisierung an Tagen geplant, die entweder dem Tag des Monats oder dem Wochentag entsprechen. Beispielsweise plant SCHEDULE = 'USING CRON 0 0 10-20 * TUE,THU UTC' eine Aktualisierung um 0:00 Uhr an jedem 10. bis 20. Tag des Monats und auch an jedem Dienstag oder Donnerstag außerhalb dieser Tage.

• num MINUTE

  Gibt ein Intervall (in Minuten) der Wartezeit zwischen den Aktualisierungen an. Akzeptiert nur positive ganze Zahlen.

  Unterstützt auch die Syntax num M.

  Um Mehrdeutigkeiten zu vermeiden, wird in folgenden Situationen eine Basisintervallzeit festgelegt:

  • Das Objekt wird erstellt (mit CREATE <Objekt>) oder

  • Ein anderes Intervall wird festgelegt (mit ALTER <Objekt> … SET REPLICATION_SCHEDULE)

  Die Basisintervallzeit startet den Intervallzähler ab der aktuellen Uhrzeit. Wenn beispielsweise ein INTERVAL-Wert von 10 festgelegt ist und die geplante Aktualisierung um 9:03 Uhr aktiviert wird, wird die Aktualisierung um 9:13 Uhr, 9:23 Uhr usw. ausgeführt. Beachten Sie, dass wir uns nach besten Kräften bemühen, absolute Präzision sicherzustellen, aber nur garantieren, dass Aktualisierungen nicht vor ihrem festgelegten Intervall ausgeführt werden (im aktuellen Beispiel könnte es sein, dass die Aktualisierung erst 9:14 Uhr ausgeführt wird, aber definitiv nicht 9:12 Uhr).

  Bemerkung

  Der maximal unterstützte Wert ist 11520 (8 Tage). Wenn der Replikationsplan einen größeren Wert num MINUTE hat, wird die Aktualisierungsoperation nie ausgeführt.

TAG tag_name = 'tag_value' [ , tag_name = 'tag_value' , ... ]

Gibt den Namen des Tags und den Wert der Tag-Zeichenfolge an.

Der Tag-Wert ist immer eine Zeichenfolge, die maximale 256 Zeichen lang sein kann.

Weitere Informationen zur Angabe von Tags in einer Anweisung finden Sie unter Tag-Kontingente für Objekte und Spalten.

ADD db_name [ , db_name ,  ... ] TO ALLOWED_DATABASES

Gibt eine durch Kommas getrennte Liste zusätzlicher Datenbanken an, die für Replikation und Failover aktiviert werden sollen. Um Datenbanken hinzuzufügen, muss DATABASES in der Liste der angegebenen Objekttypen enthalten sein. Wenn DATABASES noch nicht in der Liste der Objekttypen enthalten ist, müssen Sie diesen Typ hinzufügen.

db_name

Gibt den Bezeichner der Datenbank an.

MOVE DATABASES db_name [ , db_name ,  ... ] TO FAILOVER GROUP move_to_fg_name

Gibt eine durch Kommas getrennte Liste von Datenbanken an, die von einer Failover-Gruppe in eine andere Failover-Gruppe verschoben werden sollen. Bei der Failover-Gruppe, in die die Datenbanken verschoben werden, muss DATABASES in der Liste der angegebenen Objekttypen enthalten sein.

db_name

Gibt den Bezeichner der Datenbank an.

move_to_fg_name

Gibt den Bezeichner für die Failover-Gruppe an, in die die Datenbanken verschoben werden sollen.

REMOVE db_name [ , db_name ,  ... ] FROM ALLOWED_DATABASES

Gibt eine durch Kommas getrennte Liste von Datenbanken an, die aus der Liste der für Replikation und Failover aktivierten Datenbanken entfernt werden sollen.

Bemerkung

Wenn Sie eine Datenbank aus einer primären Failover-Gruppe entfernen, wird die Datenbank bei der nächsten Aktualisierungsoperation in jedem Zielkonto mit einer verknüpften sekundären Failover-Gruppe gelöscht.

Um zu vermeiden, dass Datenbanken im Zielkonto gelöscht werden, können Sie die sekundäre Failover-Gruppe löschen, bevor die geänderte primäre Failover-Gruppe das nächste Mal in das Zielkonto repliziert wird. Wenn Sie die sekundäre Failover-Gruppe löschen, werden die schreibgeschützten Sekundärdatenbanken, die in der Gruppe enthalten waren, zu eigenständigen Datenbanken mit Lese-/Schreib-Zugriff im Zielkonto.

ADD share_name [ , share_name ,  ... ] TO ALLOWED_SHARES

Gibt eine durch Kommas getrennte Liste zusätzlicher Freigaben an, die für Replikation und Failover aktiviert werden sollen. Um Freigaben hinzuzufügen, muss SHARES in der Liste der angegebenen Objekttypen enthalten sein. Wenn SHARES noch nicht in der Liste der Objekttypen enthalten ist, müssen Sie diesen Typ hinzufügen.

share_name

Gibt den Bezeichner der Freigabe an.

MOVE SHARES share_name [ , share_name ,  ... ] TO FAILOVER GROUP move_to_fg_name

Gibt eine durch Kommas getrennte Liste von Freigaben an, die von einer Failover-Gruppe in eine andere Failover-Gruppe verschoben werden sollen. Bei der Failover-Gruppe, in die die Freigaben verschoben werden, muss SHARES in der Liste der angegebenen Objekttypen enthalten sein.

share_name

Gibt den Bezeichner der Freigabe an.

move_to_fg_name

Gibt den Bezeichner für die Failover-Gruppe an, in die die Freigaben verschoben werden sollen.

REMOVE share_name [ , share_name ,  ... ] FROM ALLOWED_SHARES

Gibt eine durch Kommas getrennte Liste von Freigaben an, die aus der Liste der für Replikation und Failover aktivierten Freigaben entfernt werden sollen.

Bemerkung

Wenn Sie eine Freigabe aus einer primären Failover-Gruppe entfernen, wird die Freigabe bei der nächsten Aktualisierungsoperation in jedem Zielkonto mit einer sekundären Failover-Gruppe gelöscht.

ADD org_name.target_account_name [ , org_name.target_account_name ,  ... ] TO ALLOWED_ACCOUNTS

Gibt eine durch Kommas getrennte Liste von Zielkonten an, die der primären Failover-Gruppe hinzugefügt werden sollen, um Replikation und Failover der angegebenen Objekte vom Quellkonto in das Zielkonto zu aktivieren. Sekundäre Failover-Gruppen in den Zielkonten dieser Liste können im Falle eines Failovers zur primären Failover-Gruppe heraufgestuft werden.

org_name

Name Ihrer Snowflake-Organisation.

target_account_name

Zielkonto, für das Sie die Replikation der angegebenen Objekte aktivieren.

REMOVE org_name.target_account_name [ , org_name.target_account_name ,  ... ] FROM ALLOWED_ACCOUNTS

Gibt eine durch Kommas getrennte Liste von Zielkonten an, die aus der primären Failover-Gruppe entfernt werden sollen, um die Replikation der angegebenen Objekte vom Quellkonto in das Zielkonto zu deaktivieren. Durch das Entfernen eines Zielkontos wird das Failover vom aktuellen Konto in dieses Zielkonto deaktiviert.

org_name

Name Ihrer Snowflake-Organisation.

target_account_name

Zielkonto, für das Sie die Replikation der angegebenen Objekte deaktivieren.

IGNORE EDITION CHECK

Ermöglicht das Replizieren von Objekten auf Konten in folgendem Szenario:

Die primäre Failover-Gruppe befindet sich in einem Business Critical-Konto (oder höher), und es besteht eine unterzeichnete Geschäftspartner-Vereinbarung zur Speicherung von PHI-Daten in dem Konto gemäß HIPAA- und HITRUST-Vorschriften. Allerdings besteht für eines oder mehrere der zur Replikation genehmigten Konten keine solche Vereinbarung, unabhängig davon, ob es sich um Business Critical-Konten (oder höhere) handelt.

Ein solches Szenario ist standardmäßig nicht zulässig.

Zielkonto

name

Gibt den Bezeichner der Failover-Gruppe an.

REFRESH

Aktualisiert die Objekte im (aktuellen) Zielkonto aus dem Quellkonto.

PRIMARY

Eine sekundäre Failover-Gruppe und die darin enthaltenen Objekte im (aktuellen) Zielkonto wird zur primären Gruppe heraufgestuft (im Falle eines Failovers).

SUSPEND [ IMMEDIATE ]

Anhalten der geplanten Aktualisierung der sekundären Failover-Gruppe (wenn die primäre Failover-Gruppe Aktualisierungen mit der Eigenschaft REPLICATION_SCHEDULE geplant hat).

Das optionale Schlüsselwort IMMEDIATE bricht eine geplante Aktualisierungsoperation ab, die gerade für die sekundäre Failover-Gruppe ausgeführt wird (falls es eine gibt). Beachten Sie, dass zwischen dem Zeitpunkt, an dem die Anweisung zurückkehrt, und dem Zeitpunkt, an dem der Abbruch der Aktualisierungsoperation abgeschlossen ist, eine leichte Verzögerung auftreten kann.

RESUME

Fortsetzen der geplanten Aktualisierung der sekundären Failover-Gruppe (wenn die primäre Failover-Gruppe Aktualisierungen mit der Eigenschaft REPLICATION_SCHEDULE geplant hat).

Nutzungshinweise¶

• Folgende Berechtigungen sind mindestens erforderlich:

  • Zum Aktualisieren einer sekundären Failover-Gruppe mit ALTER FAILOVER GROUP … REFRESH muss die aktive Primärrolle entweder über die OWNERSHIP- oder über die REPLICATE-Berechtigung für die Failover-Gruppe verfügen.

  • Zum Ausführen eines Failover einer sekundären Failover-Gruppe mit ALTER FAILOVER GROUP … PRIMARY muss eine Rolle entweder die OWNERSHIP- oder die FAILOVER-Berechtigung für die Failover-Gruppe haben.

  • Um weitere Änderungen an der Failover-Gruppe vorzunehmen, kann nur eine Rolle mit OWNERSHIP-Berechtigung für die Gruppe diesen SQL-Befehl ausführen.

  • Um eine Datenbank zu einer Failover-Gruppe hinzuzufügen, muss die aktive Rolle über die MONITOR-Berechtigung für die Datenbank verfügen.

  • Um eine Freigabe zu einer Failover-Gruppe hinzuzufügen, muss die aktive Rolle über die OWNERSHIP-Berechtigung für die Freigabe verfügen.

• Bezeichner für Failover-Gruppen und Replikationsgruppen in einem Konto müssen eindeutig sein.

• Anders als Datenbanken oder Freigaben müssen sich Objekte in der gleichen Failover-Gruppe befinden.

• Eine Datenbank kann nur zu einer einzigen Failover-Gruppe hinzugefügt werden.

• Eingehende Freigaben (Freigaben von Anbietern) können nicht zu einer Replikations- oder Failover-Gruppe hinzugefügt werden.

• Das Heraufstufen einer sekundären Failover-Gruppe zur primären Gruppe (im Falle eines Failovers) schlägt fehl, wenn sich eine Aktualisierung in Ausführung befindet.

• Wenn sich eine Aktualisierung in Ausführung befindet, während der Replikationsplan aktualisiert wird, wird die Aktualisierung bis zum Abschluss fortgesetzt, und bei der nächsten Aktualisierung wird der neue Plan verwendet.

• Beim Failover werden die geplanten Aktualisierungen auf allen sekundären Failover-Gruppen angehalten. ALTER FAILOVER GROUP ... RESUME muss auf jeder sekundären Gruppe ausgeführt werden, damit die automatischen Aktualisierungen fortgesetzt wird.

• So verschieben Sie Datenbanken oder Freigaben von einer Failover-Gruppe (der „Verschieben von“-Gruppe) in eine andere Failover-Gruppe (die „Verschieben nach“-Gruppe):

  • Beide Gruppen müssen vom gleichen Typ sein: FAILOVER GROUP.

  • Wenn die letzte Datenbank der „Verschieben von“-Gruppe in eine andere Gruppe verschoben wurde, wird die Eigenschaft allowed_databases für die „Verschieben von“-Gruppe auf NULL gesetzt. Das gleiche Verhalten gilt für Freigaben.

  • Wenn in der object_types-Liste der „Verschieben nach“-Gruppe nicht der Objekttyp enthalten ist, der verschoben werden soll (databases oder shares), muss dieser Typ vor dem Verschieben von Objekten explizit zur „Verschieben nach“-Gruppe hinzugefügt werden.

• Wenn Datenbank- oder Freigabeobjekte aus einer primären Failover-Gruppe entfernt werden (mit dem Parameter REMOVE oder SET, um die ALLOWED_DATABASES- oder ALLOWED_SHARES-Liste zu ändern), werden diese Objekte bei der nächsten Aktualisierungsoperation in allen Zielkonten gelöscht.

  Um zu vermeiden, dass diese Objekte im Zielkonto gelöscht werden, können Sie die sekundäre Failover-Gruppe löschen, bevor die geänderte primäre Failover-Gruppe das nächste Mal in das Zielkonto repliziert wird.

• Um die Liste der Konten in Ihrer Organisation abzurufen, die für die Replikation aktiviert sind, verwenden Sie den Befehl SHOW REPLICATION ACCOUNTS.

• Zum Abrufen der Liste der Failover-Gruppen Ihrer Organisation verwenden Sie SHOW FAILOVER GROUPS.

• Automatisch geplante Aktualisierungsoperationen werden mit der Rolle ausgeführt, die die OWNERSHIP-Berechtigung für die Gruppe hat. Wenn eine geplante Aktualisierungsoperation aufgrund unzureichender Berechtigungen fehlschlägt, erteilen Sie der Rolle mit der Berechtigung OWNERSHIP für die Gruppe die erforderlichen Berechtigungen.

• Der Befehl ALTER FAILOVER GROUP … SUSPEND IMMEDIATE bricht eine laufende Aktualisierungsoperation nicht ab, wenn sie manuell ausgelöst wurde. Weitere Informationen dazu finden Sie unter Laufende Aktualisierungsoperation abbrechen, die nicht automatisch geplant wurde.

• Das Abbrechen einer laufenden Aktualisierungsoperation, die sich in der Phase SECONDARY_DOWNLOADING_METADATA oder SECONDARY_DOWNLOADING_DATA befindet, kann zu einem inkonsistenten Zustand des Zielkontos führen. Weitere Informationen dazu finden Sie unter Aktuelle Phase einer laufenden Aktualisierungsoperation anzeigen.

• Wenn Sie eine Replikations- oder Failover-Gruppe mit einem Tag erstellen oder eine Replikations- oder Failover-Gruppe durch Festlegen eines Tags ändern, gilt Tag-Herkunft nicht für Objekte, die Sie in der Replikations- oder Failover-Gruppe angeben.

  Die Tag-Hierarchie gilt nur für Objekte mit einer Übergeordnet/Untergeordnet-Beziehung, wie Datenbank, Schema und Tabelle. Es gibt keine untergeordneten Objekte von Replikations- oder Failover-Gruppen.

• Sie können bei einer sekundären Replikation oder Failover-Gruppe kein Tag festlegen oder ändern, da diese Objekte schreibgeschützt sind.

• Wenn Sie eine sekundäre Replikations- oder Failover-Gruppe aktualisieren, werden alle Tags, die in der primären Gruppe festgelegt sind, auch in der sekundären Gruppe festgelegt.

• Hinweis zu Metadaten:

  Achtung

  Kunden müssen sicherstellen, dass bei der Nutzung des Snowflake-Dienstes keine personenbezogenen Daten (außer für ein Objekt „Benutzer“), sensible Daten, exportkontrollierte Daten oder andere regulierte Daten als Metadaten eingegeben werden. Weitere Informationen dazu finden Sie unter Metadatenfelder in Snowflake.

Beispiele¶

ALTER FAILOVER GROUP myfg ADD myorg.myaccount3 TO ALLOWED_ACCOUNTS;

ALTER FAILOVER GROUP myfg SET
  OBJECT_TYPES = USERS, ROLES, WAREHOUSES, RESOURCE MONITORS, DATABASES
  ALLOWED_DATABASES = db1;

ALTER FAILOVER GROUP myfg
  ADD db2, db3 TO ALLOWED_DATABASES;

ALTER FAILOVER GROUP myfg
  MOVE DATABASES db3 TO FAILOVER GROUP myfg2;

ALTER FAILOVER GROUP myfg
  SET ALLOWED_DATABASES = NULL;

ALTER FAILOVER GROUP myfg
  REMOVE databases FROM OBJECT_TYPES;

ALTER FAILOVER GROUP myfg
  SET REPLICATION_SCHEDULE = '15 MINUTE';

ALTER FAILOVER GROUP myfg REFRESH;

ALTER FAILOVER GROUP myfg PRIMARY;

ALTER FAILOVER GROUP myfg SUSPEND;