Replizieren von Datenbanken und Kontoobjekten über mehrere Konten hinweg¶

Schritt 1: Replikation bei einer replikationsfähigen Datenbank deaktivieren¶

Führen Sie die Funktion SYSTEM$DISABLE_DATABASE_REPLICATION aus, um die Replikation bei einer Primärdatenbank und bei allen mit ihr verknüpften Sekundärdatenbanken zu deaktivieren, um sie zu einer Replikations- oder Failover-Gruppe hinzufügen zu können.

Führen Sie die folgende SQL-Anweisung von dem Quellkonto aus, das die Primärdatenbank enthält:

SELECT SYSTEM$DISABLE_DATABASE_REPLICATION('mydb');

Schritt 2: Datenbank zu primärer Failover-Gruppe hinzufügen und sekundäre Failover-Gruppe erstellen¶

Nachdem Sie die Replikation für eine Datenbank erfolgreich deaktiviert haben, können Sie die Primärdatenbank nun zu einer Failover-Gruppe im Quellkonto hinzufügen.

Erstellen Sie dann eine sekundäre Failover-Gruppe im Zielkonto. Wenn die sekundäre Failover-Gruppe im Zielkonto aktualisiert wird, werden alle bisherigen Sekundärdatenbanken automatisch als Mitglieder der sekundären Failover-Gruppe hinzugefügt und mit den Änderungen der Primärdatenbank aktualisiert.

Weitere Informationen zum Erstellen von primären und sekundären Failover-Gruppen finden Sie unter Workflow.

Beispiele¶

Führen Sie die folgenden SQL-Anweisungen in Ihrem bevorzugten Snowflake-Client aus, um Replikation und Failover der Konto- und Datenbankobjekte zu aktivieren und die Objekte zu aktualisieren.

Voraussetzung: Aktivieren Sie die Replikation für Konten der Organisation¶

Der Organisationsadministrator (Rolle ORGADMIN) muss die Replikation für das Quell- und das Zielkonto aktivieren.

Zum Aktivieren der Replikation eines Kontos muss ein Benutzer mit der Rolle ORGADMIN mithilfe der Funktion SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER den Parameter ENABLE_ACCOUNT_DATABASE_REPLICATION auf true setzen. Beachten Sie, dass die Replikation für mehrere Konten einer Organisation von demselben ORGADMIN-Konto aus aktiviert werden kann.

Melden Sie sich bei einem ORGADMIN-Konto an, um die Replikation für jedes Quell- und Zielkonto Ihrer Organisation zu aktivieren.

USE ROLE ORGADMIN;

-- View the list of the accounts in your organization
-- Note the organization name and account name for each account for which you are enabling replication
SHOW ORGANIZATION ACCOUNTS;

-- Enable replication by executing this statement for each source and target account in your organization
SELECT SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER('<organization_name>.<account_name>', 'ENABLE_ACCOUNT_DATABASE_REPLICATION', 'true');

Obwohl die Funktion SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER den alten Konto-Locator als Bezeichner unterstützt, kann dies zu unerwarteten Ergebnissen führen, wenn eine Organisation mehrere Konten mit demselben Konto-Locator (in verschiedenen Regionen) verwendet.

Schritt 1: Rolle mit CREATE FAILOVER GROUP-Berechtigung im Quellkonto erstellen – Optional¶

Erstellen Sie eine Rolle, und erteilen Sie dieser Rolle die Berechtigung CREATE FAILOVER GROUP. Dieser Schritt ist optional. Wenn Sie diese Rolle bereits erstellt haben, fahren Sie mit Schritt 2: Primäre Failover-Gruppe in einem Quellkonto erstellen fort.

USE ROLE ACCOUNTADMIN;

CREATE ROLE myrole;

GRANT CREATE FAILOVER GROUP ON ACCOUNT
    TO ROLE myrole;

Schritt 2: Primäre Failover-Gruppe in einem Quellkonto erstellen¶

Erstellen Sie eine primäre Failover-Gruppe, und aktivieren Sie die Replikation und das Failover der angegebenen Objekte vom aktuellen (Quell-)Konto in ein oder mehrere Zielkonten derselben Organisation.

SHOW REPLICATION ACCOUNTS;

+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| snowflake_region | created_on                    | account_name | account_locator | comment         | organization_name | is_org_admin |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| AWS_US_WEST_2    | 2020-07-15 21:59:25.455 -0800 | myaccount1   | myacctlocator1  |                 | myorg             | true         |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| AWS_US_EAST_1    | 2020-07-23 14:12:23.573 -0800 | myaccount2   | myacctlocator2  |                 | myorg             | false        |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| AWS_US_EAST_2    | 2020-07-25 19:25:04.412 -0800 | myaccount3   | myacctlocator3  |                 | myorg             | false        |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+

USE ROLE myrole;

CREATE FAILOVER GROUP myfg
    OBJECT_TYPES = USERS, ROLES, WAREHOUSES, RESOURCE MONITORS, DATABASES, INTEGRATIONS, NETWORK POLICIES
    ALLOWED_DATABASES = db1, db2
    ALLOWED_INTEGRATION_TYPES = API INTEGRATIONS
    ALLOWED_ACCOUNTS = myorg.myaccount2
    REPLICATION_SCHEDULE = '10 MINUTE';

Schritt 3: Rolle mit CREATE FAILOVER GROUP-Berechtigung im Zielkonto erstellen – Optional¶

Erstellen Sie eine Rolle im Zielkonto, und erteilen Sie dieser Rolle die Berechtigung CREATE FAILOVER GROUP. Dieser Schritt ist optional. Wenn Sie diese Rolle bereits erstellt haben, fahren Sie mit Schritt 4: Sekundäre Failover-Gruppe im Zielkonto erstellen fort.

USE ROLE ACCOUNTADMIN;

CREATE ROLE myrole;

GRANT CREATE FAILOVER GROUP ON ACCOUNT
    TO ROLE myrole;

Schritt 4: Sekundäre Failover-Gruppe im Zielkonto erstellen¶

Erstellen Sie eine sekundäre Failover-Gruppe im Zielkonto als Replikat der primären Failover-Gruppe aus dem Quellkonto.

Führen Sie eine CREATE FAILOVER GROUP … AS REPLICA OF-Anweisung in jedem Zielkonto aus, für das Sie die Replikation in Schritt 2: Primäre Failover-Gruppe in einem Quellkonto erstellen (unter diesem Thema) aktiviert haben.

Von jedem Zielkonto ausführen:

USE ROLE myrole;

CREATE FAILOVER GROUP myfg
  AS REPLICA OF myorg.myaccount1.myfg;

Schritt 5: Sekundäre Failover-Gruppe im Zielkonto manuell erstellen – Optional¶

Um die Objekte in einem Zielkonto manuell zu aktualisieren, führen Sie den Befehl ALTER FAILOVER GROUP … REFRESH aus.

Als bewährte Methode empfehlen wir, die sekundären Aktualisierungen durch Einstellen des REPLICATION_SCHEDULE-Parameters mit CREATE FAILOVER GROUP oder ALTER FAILOVER GROUP zu planen.

SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME() zum Anwenden von globalen IDs verwenden¶

Sie können den Verlust einiger Objekttypen verhindern, indem Sie übereinstimmende Objekte mit demselben Namen in Quell- und Zielkonto verknüpfen. Die Funktion SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME fügt den Kontoobjekten des Zielkontos eine globale ID hinzu.

Wenden Sie globale Bezeichner auf Kontoobjekte im Zielkonto an, die in der Liste object_types für die Failover-Gruppe myfg enthalten sind:

Führen Sie die folgende SQL-Anweisung mit der Rolle ACCOUNTADMIN aus:

SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('myfg');

Erstmalige Replikation von Benutzern und Rollen¶

Das Verhalten bei der erstmaligen Aktualisierungsoperation der Objekttypen USERS und ROLES kann variieren, je nachdem, ob es im Zielkonto übereinstimmende Objekte mit demselben Namen gibt oder nicht.

• Wenn es im Zielkonto bereits Benutzer mit demselben Namen wie im Quellkonto gibt, schlägt die erste Aktualisierungsoperation fehl. Es gibt nun zwei Optionen um fortzufahren:

  • Die Aktualisierungsoperation wird erzwungen, und es wird zugelassen, dass alle vorhandenen Benutzer und/oder Rollen im Zielkonto gelöscht werden. Die Benutzer des Quellkontos werden in das Zielkonto repliziert.

    Um eine Aktualisierung für eine Gruppe zu erzwingen, verwenden Sie im REFRESH-Befehl den Parameter FORCE. Um beispielsweise die Aktualisierung einer Failover-Gruppe zu erzwingen, führen Sie den folgenden Befehl aus:

    ALTER FAILOVER GROUP <fg_name> REFRESH FORCE;
    

    Copy

  • Die Kontoobjekte werden nach Namen verknüpft. Die Funktion SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME verknüpft Benutzer, die im Zielkonto und im Quellkonto denselben Namen haben. Im Zielkonto verknüpfte Benutzer werden nicht gelöscht.

    Um Kontoobjekte über ihren Namen zu verknüpfen, führen Sie den folgenden Befehl aus:

    SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('<rg_name>');
    

    Copy

    Bemerkung

    Jeder Benutzer im Zielkonto, für den es im Quellkonto keinen übereinstimmenden Benutzer mit demselben Namen gibt, wird gelöscht.

• Wenn es im Zielkonto keine Benutzer gibt, deren Namen mit denen der Benutzer im Quellkonto übereinstimmen, werden bei der ersten Aktualisierungsoperation alle Benutzer im Zielkonto gelöscht. Dies kann zu folgenden Verlusten von Daten und Metadaten führen:

  • Wenn USERS in der Liste OBJECT_TYPES einer Replikations- oder Failover-Gruppe enthalten ist, passiert Folgendes:

    • Arbeitsblätter gehen verloren

    • Abfrageverlauf geht verloren

  • Wenn USERS in der Liste OBJECT_TYPES enthalten ist, ROLES aber nicht, passiert Folgendes:

    • Berechtigungen für Benutzer gehen verloren

  • Wenn ROLES in der Liste OBJECT_TYPES enthalten ist, passiert Folgendes:

    • Berechtigungen zur Freigabe von Objekten gehen verloren

So verhindern Sie, dass Benutzer oder Rollen im Zielkonto gelöscht werden:

1. Erstellen Sie vor der ersten Replikation im Quellkonto manuell alle Benutzer oder Rollen neu, die nur im Zielkonto vorhanden sind.

2. Verknüpfen Sie im Zielkonto übereinstimmende Objekte mit dem gleichen Namen in beiden Konten mit der Funktion SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME.

Amazon S3¶

Der Konfigurationsprozess hängt davon ab, wie Sie die Ereignisbenachrichtigungen einrichten. Angenommen, Sie haben eine Auto-Erfassungs-Pipe, die auf ein Amazon Simple Notification Service (SNS)-Thema angewiesen ist, um Meldungen zum Standort des Snowflake-Stagingbereichs zu veröffentlichen.

Wenn Sie die Pipe auf ein Zielkonto replizieren, erstellt Snowflake automatisch eine neue Amazon Simple Queue Service (SQS)-Warteschlange. Sie müssen diese SQS-Warteschlange für Ihr Zielkonto beim SNS-Thema abonnieren, um Benachrichtigungen zum Speicherort des Stagingbereichs zu erhalten.

• Wenn Sie Amazon S3-Ereignisbenachrichtigungen mit Amazon Simple Queue Service (SQS) verwenden, folgen Sie den Anweisungen unter Schritt 4: Ereignisbenachrichtigungen konfigurieren.

  Wichtig

  Um sicherzustellen, dass die Pipe keine Benachrichtigungen verpasst hat, müssen Sie die Pipe nach dem Wechsel zur neuen SQS-Warteschlange aktualisieren.

  Sie können auch von SQS nach SNS migrieren. Weitere Informationen dazu finden Sie unter Migration zu Amazon Simple Notification Service (SNS).

• Wenn Sie Amazon Simple Notification Service (SNS) verwenden, finden Sie weitere Informationen unter Abonnieren der Snowflake-SQS-Warteschlange zu Ihrem SNS-Thema.

• Wenn Sie Amazon EventBridge verwenden, finden Sie weitere Informationen unter Option 3: Einrichten von Amazon EventBridge zum Automatisieren von Snowpipe.

Microsoft Azure Blob Storage¶

Eine Pipe, die automatisch Daten aus Dateien lädt, die sich in einem Stagingbereich in Microsoft Azure Blob Storage befinden, erfordert ein Event Grid-Abonnement, eine Speicherwarteschlange und eine an die Speicherwarteschlange gebundene Benachrichtigungsintegration. Eine sekundäre Pipe in einem Zielkonto benötigt ein separates Event Grid, eine Speicherwarteschlange und eine an die Speicherwarteschlange gebundene Benachrichtigungsintegration. Das Event Grid in Quell- und Zielkonten muss als Endpunkte für dieselbe Azure Storage-Quelle konfiguriert sein.

Weitere Informationen zur Konfiguration finden Sie im nachstehenden Diagramm:

Erstellen Sie ein neues Event Grid-Abonnement und eine Speicherwarteschlange. Erstellen Sie dann eine neue Benachrichtigungsintegration im Zielkonto und gewähren Sie Snowflake Zugriff auf Ihre Speicherwarteschlange. Eine Anleitung dazu finden Sie unter Konfigurieren der Automatisierung mit Azure Event Grid.

Externer Stagingbereich für Google Cloud Storage¶

Eine Pipe, die automatisch Daten aus Dateien in Google Cloud Storage lädt, erfordert ein Google Pub/Sub-Abonnement und eine Benachrichtigungsintegration, die auf dieses Abonnement verweist. Jede replizierte Pipe in einem Zielkonto erfordert außerdem ein Google Pub/Sub-Abonnement und eine Benachrichtigungsintegration, die auf dieses Abonnement verweist. Das Pub/Sub-Abonnement in jedem Quell- und Zielkonto muss auf dasselbe Pub/Sub-Thema abonniert sein, das Benachrichtigungen von der Google Cloud Storage-Quelle erhält.

Weitere Informationen zur Konfiguration finden Sie im nachstehenden Diagramm:

Erstellen Sie ein neues Abonnement für Ihr Pub/Sub-Thema und eine neue Benachrichtigungsintegration in Ihrem Zielkonto.

Gewähren Sie dann Snowflake Zugriff auf das Pub/Sub-Abonnement. Eine Anleitung dazu finden Sie unter Konfigurieren von automatischem Snowpipe mit GCS Pub/Sub.

Replikation mit Snowsight überwachen¶

Um den Replikationsfortschritt und -status für Replikations- und Failover-Gruppen einer Organisation zu überwachen, verwenden Sie die Seite Replication in Snowsight.

Sie können den Status und die Details der Aktualisierungsoperationen anzeigen:

• Zeigen Sie den aktuellen Status der letzten Aktualisierungsoperation an.

• Zeigen Sie die Verzögerungszeit des Replikats an (Zeit seit der letzten Aktualisierungsoperation).

• Zeigen Sie die Verteilung der Verzögerungszeiten der Replikate in den einzelnen Gruppen an.

• Datum und Uhrzeit der nächsten geplanten Aktualisierungsoperation.

Um den Replikationsstatus der einzelnen Replikations- oder Failover-Gruppen anzuzeigen, führen Sie die folgenden Schritte aus:

1. Melden Sie sich bei Snowsight an, und navigieren Sie zu Admin » Accounts.

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

Auf der Seite Groups werden Details zur Aktualisierungsoperation für alle Gruppen angezeigt, für die Ihre Rolle eine Berechtigung zum Anzeigen hat. Sie können die Kacheln verwenden, um die Ansicht zu filtern.

• Wenn zum Beispiel die Kachel Status anzeigt, dass Aktualisierungsoperationen fehlgeschlagen sind, können Sie die Kachel auswählen, um fehlerhafte Gruppen zu untersuchen.

• Die Verzögerungszeit in der Kachel Longest Replication lag bezieht sich auf die Zeitspanne seit der letzten Aktualisierungsoperation. Dies ist die Zeitspanne, die die sekundäre Replikations- oder Failover-Gruppe hinter der primären Gruppe zurückbleibt. Die längste Verzögerungszeit ist die Zeitspanne, die seit der letzten Aktualisierung der ältesten sekundären Replikationsgruppe vergangen ist.

  Wenn Sie beispielsweise drei Failover-Gruppen fg_1, fg_2, fg_3 mit unabhängigen Replikationsplänen von jeweils 10 Minuten, 2 Stunden und 12 Stunden haben, kann die längste Verzögerungszeit bis zu 12 Stunden betragen. Wenn fg_3 jedoch erst kurz zuvor im Zielkonto aktualisiert wurde, wird deren Verzögerungszeit auf 0 zurückgesetzt, und eine andere Failover-Gruppe kann eine längere Verzögerungszeit haben.

• Sie können einen einzelnen Balken in der Kachel Group Lag Distribution auswählen, um die Ergebnisse auf eine einzelne Gruppe zu filtern.

Sie können Gruppen auch mithilfe des Suchfeldes oder der Dropdown-Menüs filtern:

• Sie können über das Feld (Suche) nach dem Namen der Replikations- oder Failover-Gruppe suchen.

• Wählen Sie Type aus, um die Ergebnisse nach Replikations- oder Failover-Gruppe zu filtern.

• Wählen Sie Replicating aus, um nach primären (To auswählen) oder sekundären Gruppen (From auswählen) zu filtern.

• Wählen Sie das Menü (Konten) aus, um die Ergebnisse nach Kontonamen zu filtern.

• Wählen Sie Status aus, um die Ergebnisse nach dem Status der Aktualisierungsoperation zu filtern:

  • Refresh Cancelled

  • Refresh Failed

  • Refresh In Progress

  • Refresh Successful

Die folgenden Details werden zu Ihren Replikations- und Failover-Gruppen angezeigt:

Sie können eine Replikations- oder Failover-Gruppe auswählen, um detaillierte Informationen über jede Aktualisierungsoperation anzuzeigen. Weitere Informationen dazu finden Sie im Abschnitt zum Replikationsverlauf in Snowsight.

Fortschritt von Aktualisierungsoperationen überwachen¶

In diesem Abschnitt erfahren Sie, wie Sie den Replikationsfortschritt für eine bestimmte Replikations- oder Failover-Gruppe überwachen können.

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

Anzeigen des Replikationsverlaufs¶

Sie können den Replikationsverlauf mit Snowsight oder mit SQL anzeigen.

Replikationsverlauf mit Snowsight anzeigen¶

Sie können den Replikationsverlauf und die Details zu jeder Aktualisierungsoperation für eine bestimmte Replikations- oder Failover-Gruppe auf der Detailseite der Gruppe anzeigen.

1. Melden Sie sich bei Snowsight an, und navigieren Sie zu Admin » Accounts.

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

3. Wählen Sie den Namen einer Replikations- oder Failover-Gruppe aus.

Die folgenden Informationen zu der Gruppe werden angezeigt:

• Gruppentyp (Replikationsgruppe oder Failover-Gruppe)

• Replikationsplan (z. B. alle 10 Minuten)

• Dauer der einzelnen Aktualisierungsoperationen

• Verzögerungszeit der Replikate (Zeitspanne seit dem letzten Aktualisierungsoperation)

• Datum und Uhrzeit der nächsten geplanten Aktualisierungsoperation

Sie können die Daten auf der Seite nach Status und Zeitraum filtern:

• Wählen Sie Status aus, um die Ergebnisse nach dem Status der Aktualisierungsoperation zu filtern:

  • Refresh Cancelled

  • Refresh Failed

  • Refresh In Progress

  • Refresh Successful

• Wählen Sie Duration aus, um folgende Details zur Aktualisierungsoperation anzuzeigen:

  • Last hour

  • Last 24 hours

  • Last 7 days

  • All

  Wenn Sie All auswählen, werden die Aktualisierungsoperationen der letzten 14 Tage angezeigt.

Die Details zu jeder Aktualisierungsoperation umfassen die folgenden Spalten:

Spalte	Beschreibung
Query ID	Abfrage-ID der Aktualisierungsoperation.
Status	Zeigt den Status der Aktualisierungsoperation an. Gültige Werte sind Successful, Failed, In Progress.
Ended	Datum und Uhrzeit, zu der die Aktualisierungsoperation beendet wurde.
Duration	Zeitdauer für die Ausführung der Aktualisierungsoperation. Die Dauer ist nach Replikationsphasen aufgeschlüsselt und farblich gekennzeichnet. Die Breite jedes farbigen Segments zeigt an, wie viel Zeit in dieser Phase verbracht wurde. Die Abbildung unten dient nur als Referenz. Diese Darstellung ist verfügbar, wenn Sie die Aktualisierungsoperation auswählen, um weitere Details anzuzeigen.
Transferred	Anzahl der replizierten Bytes.
Objects	Anzahl der replizierten Objekte.

Wählen Sie eine Zeile aus, um zusätzliche Details zu einer bestimmten Aktualisierungsoperation anzuzeigen:

• Dauer der einzelnen Replikationsphasen

• Fehlermeldung (bei fehlgeschlagenen Aktualisierungsoperationen)

• Liste der replizierten Datenbankobjekte nach Typ und Anzahl

• Anzahl der replizierten Datenbanken und Datenbanknamen

SELECT PHASE_NAME, START_TIME, END_TIME, TOTAL_BYTES, OBJECT_COUNT
  FROM TABLE(information_schema.replication_group_refresh_history('myfg'))
  WHERE START_TIME >= current_date - interval '7 days';

SELECT REPLICATION_GROUP_NAME, PHASE_NAME, START_TIME, END_TIME, TOTAL_BYTES, OBJECT_COUNT
  FROM snowflake.account_usage.replication_group_refresh_history
  WHERE START_TIME >= date_trunc('month', current_date());

Replikationskosten überwachen¶

Um die Credit-Nutzung für die Replikation zu überwachen, können Sie folgende Abfragen ausführen:

• Ansicht REPLICATION_GROUP_USAGE_HISTORY (in Account Usage)

• Tabellenfunktion REPLICATION_GROUP_USAGE_HISTORY (in Snowflake Information Schema)

SELECT start_time, end_time, replication_group_name, credits_used, bytes_transferred
  FROM table(information_schema.replication_group_usage_history(date_range_start=>dateadd('day', -7, current_date())));

SELECT start_time, 
  end_time, 
  replication_group_name, 
  credits_used, 
  bytes_transferred
FROM snowflake.account_usage.replication_group_usage_history
WHERE start_time >= DATE_TRUNC('month', CURRENT_DATE());

Replikationskosten für Datenbanken überwachen¶

Die Kosten für die Replikation einer einzelnen Datenbank, die zu einer Replikations- oder Failover-Gruppe gehört, können berechnet werden, indem die Anzahl der kopierten Bytes für die Datenbank abgerufen und mit den verwendeten Credits verknüpft wird.

Beispiel¶

In den folgenden Beispielen ist die Datenbank mydb in der Failover-Gruppe myfg enthalten. Die Datenbank mydb enthält die Tabelle mytable.

Replikations- oder Failover-Gruppe mit Snowsight ändern¶

Um den Namen der Gruppe zu bearbeiten, müssen Sie bei dem Zielkonto angemeldet sein. Wenn Sie nicht angemeldet sind, wird in der Spalte Status anstelle des Aktualisierungsstatus eine Anmeldemeldung angezeigt.

Sowohl das Quellkonto als auch das Zielkonto müssen denselben Verbindungstyp (öffentliches Internet) verwenden. Andernfalls schlägt die Anmeldung bei dem Zielkonto fehl.

1. Melden Sie sich bei Snowsight an, und navigieren Sie zu Admin » Accounts.

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

3. Suchen Sie die Replikations- oder Failover-Gruppe, die Sie bearbeiten möchten. Wählen Sie in der letzten Spalte der Zeile das Menü More (…) aus.

4. Wählen Sie Edit aus.

5. Um den Gruppennamen zu ändern, geben Sie in das Feld Group Name einen neuen Namen ein, der die folgenden Anforderungen erfüllt:

   • Der Bezeichner muss mit einem alphabetischen Zeichen beginnen und darf keine Leer- oder Sonderzeichen enthalten, es sei denn, die gesamte Bezeichnerzeichenfolge wird in doppelte Anführungszeichen gesetzt (z. B. „Mein Objekt“). Bei Bezeichnern, die in doppelte Anführungszeichen eingeschlossen sind, ist auch die Groß-/Kleinschreibung zu beachten.

     Weitere Informationen dazu finden Sie unter Anforderungen an Bezeichner.

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

6. Wählen Sie Select Objects aus, um Freigabe- und Kontoobjekte hinzuzufügen oder zu entfernen.

   Bemerkung

   Kontoobjekte können nur zu einer einzigen Replikations- oder Failover-Gruppe hinzugefügt werden. Wenn in Ihrem Konto bereits eine Replikations- oder Failover-Gruppe mit Kontoobjekten vorhanden ist, können Sie diese Objekte nicht auswählen.

7. Wählen Sie Select Databases aus, um Datenbankobjekte hinzuzufügen oder zu entfernen.

8. Wählen Sie die Replication Frequency aus, um den Replikationsplan einer Gruppe zu ändern.

9. Wählen Sie Save Changes aus, um die Gruppe zu aktualisieren.

   Wenn das Speichern der Änderungen an der Gruppe nicht erfolgreich war, finden Sie unter Probleme beim Erstellen und Bearbeiten von Replikationsgruppen in Snowsight beheben Informationen zu häufigen Fehlern und deren Behebung.

Replikations- oder Failover-Gruppe mit SQL ändern¶

Sie können die Eigenschaften einer Replikations- oder Failover-Gruppe mit dem Befehl ALTER REPLICATION GROUP oder ALTER FAILOVER GROUP ändern.

Primäre Replikations- oder Failover-Gruppe mit SQL löschen¶

Eine primäre Replikations- oder Failover-Gruppe kann erst gelöscht werden, nachdem alle Replikate der Gruppe (d. h. alle sekundären Replikations- oder Failover-Gruppen) gelöscht wurden. Alternativ können Sie eine sekundäre Failover-Gruppe zur primären Failover-Gruppe heraufstufen und dann die bisherige primäre Failover-Gruppe löschen.

Beachten Sie, dass die Gruppe nur vom Eigentümer der Gruppe gelöscht werden kann.

Replikations- oder Failover-Gruppe mit Snowsight löschen¶

Sie können eine primäre Replikations- oder Failover-Gruppe und alle damit verknüpften sekundären Gruppen löschen.

1. Melden Sie sich bei Snowsight an, und navigieren Sie zu Admin » Accounts.

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

3. Suchen Sie die Replikations- oder Failover-Gruppe, die Sie löschen möchten. Wählen Sie in der letzten Spalte der Zeile das Menü More (…) aus.

4. Wählen Sie Drop und dann Drop Group aus.

Eine Datenbank kann nicht zu einer Gruppe hinzugefügt werden¶

Database '<database_name>' is already configured to replicate to
account '<account_name>' by replication group '<group_name>'.

Cannot directly add previously replicated object '<database_name>' to a
replication group. Please use the provided system functions to convert
this object first.

Eine Freigabe kann nicht zu einer Gruppe hinzugefügt werden¶

Share '<share_name>' is already configured to replicate to
account '<account_name>' by replication group '<group_name>'.