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 Administrator der Organisation muss die Replikation für die Quell- und Zielkonten 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 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.

Schritt 6: Rolle FAILOVER-Berechtigung für Failover-Gruppe erteilen – Optional¶

Um den Failover-Befehl für eine sekundäre Replikations- oder Failover-Gruppe im Zielkonto auszuführen, müssen Sie eine Rolle mit FAILOVER-Berechtigung für die Failover-Gruppe verwenden. Die Berechtigung FAILOVER wird derzeit nicht repliziert und muss in jedem Quell- und Zielkonto zugewiesen werden.

Weitere Informationen dazu finden Sie unter Replikation von Rollen und Berechtigungszuweisungen.

Um beispielsweise der Rolle my_failover_role die Berechtigung FAILOVER für die Failover-Gruppe my_fg zu erteilen, führen Sie die folgende Anweisung im Zielkonto mit einer Rolle aus, die über OWNERSHIP-Berechtigung für die Gruppe verfügt:

GRANT FAILOVER ON FAILOVER GROUP myfg TO ROLE my_failover_role;

Eine Anleitung zum Erstellen einer kundenspezifischen Rolle mit einer bestimmten Gruppe von Berechtigungen finden Sie unter Erstellen von kundenspezifischen Rollen.

Allgemeine Informationen zu Rollen und Berechtigungen zur Durchführung von SQL-Aktionen auf sicherungsfähigen Objekten finden Sie unter Übersicht zur Zugriffssteuerung.

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.

Beispiel¶

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

Ändern einer Replikations- oder Failover-Gruppe in einem Konto mit Snowsight¶

Um diese Aktionen durchführen zu können, müssen Sie bei dem Quellkonto angemeldet sein. Wenn Sie nicht angemeldet sind, wird in der Spalte Status anstelle des Aktualisierungsstatus eine Anmeldemeldung angezeigt.

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, und wählen Sie das Menü More (…) in der letzten Spalte der Zeile.

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:

   • Muss mit einem Buchstaben beginnen und darf keine Leer- oder Sonderzeichen enthalten, es sei denn, der Bezeichner ist in doppelte Anführungszeichen eingeschlossen (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.

Ändern Sie eine Replikations- oder Failover-Gruppe in einem Quellkonto mit SQL¶

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

Anhalten oder Fortsetzen eines Replikationsplans in einem Zielkonto mit Snowsight¶

Um einen Replikationsplan anzuhalten oder fortzusetzen, müssen Sie bei dem Zielkonto angemeldet sein.

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, und wählen Sie das Menü More (…) in der letzten Spalte der Zeile.

4. Wählen Sie Pause oder Resume aus.

Anhalten oder Fortsetzen eines Replikationsplans in einem Zielkonto mit SQL¶

Sie können einen Replikationsplan in einem Zielkonto mit dem Befehl ALTER REPLICATION GROUP oder ALTER FAILOVER GROUP anhalten oder fortsetzen. Um zu pausieren, geben Sie den Parameter SUSPEND an. Um fortzufahren, geben Sie den Parameter RESUME an.

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. die 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>'.