Replizieren von Datenbanken und Kontoobjekten über mehrere Konten hinweg

Unter diesem Thema werden die Schritte beschrieben, die zum Replizieren von Kontoobjekten und Daten über mehrere Snowflake-Konten derselben Organisation hinweg und zum Synchronisieren der Objekte und Daten erforderlich sind. Die Kontoreplikation kann über Snowflake-Konten in verschiedenen Regionen und auf verschiedenen Cloudplattformen hinweg erfolgen.

Bemerkung

Wenn Sie ein Konto auf die Business Critical Edition (oder höher) aktualisieren, kann es bis zu 12 Stunden dauern, bis die Failover-Funktionen zur Verfügung stehen.

Unter diesem Thema:

Unterstützung von Replikation und Failover/Failback in den Regionen

Kunden können die Replikation über alle Region innerhalb einer Regionsgruppe hinweg ausführen. Wenn Sie die Replikation zwischen Regionen in verschiedenen Regionsgruppen ausführen möchten (z. B. von einer kommerziellen Snowflake-Region zu einer Snowflake-Region für Regierungsbehörden), wenden Sie sich an den Snowflake-Support, um den Zugriff zu aktivieren.

Umstellen von Datenbankreplikation auf gruppenbasierte Replikation

Bei Datenbanken, bei denen die Replikation mit ALTER DATABASE aktiviert worden war, muss die Replikation erst wieder deaktiviert werden, bevor die Datenbanken zu einer Replikations- oder Failover-Gruppe hinzugefügt werden können.

Bemerkung

Führen Sie die SQL-Anweisungen in diesem Abschnitt mit der Rolle ACCOUNTADMIN aus.

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');
Copy

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.

Bemerkung

Wenn Sie eine zuvor replizierte Datenbank zu einer Failover-Gruppe hinzufügen, führt Snowflake keine erneute Replikation der Daten durch, die bereits für diese Datenbank repliziert wurden. Beim Aktualisieren der Gruppe werden nur die Änderungen seit der letzten Aktualisierung repliziert.

Workflow

Die folgenden SQL-Anweisungen demonstrieren den Ablauf für das Aktivieren der Replikation von Konto- und Datenbankobjekten und das Aktualisieren der Objekte. Jeder Schritt wird im Folgenden ausführlich erläutert.

Bemerkung

Für die folgenden Beispiele muss die Replikation für das Quell- und das Zielkonto aktiviert sein. Weitere Details dazu finden Sie unter Voraussetzung: Aktivieren Sie die Replikation für Konten der Organisation.

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.

Von Quellkonto ausführen

  1. Erstellen Sie eine Rolle, und erteilen Sie dieser Rolle die Berechtigung CREATE FAILOVER GROUP. Der folgende Schritt ist optional:

    USE ROLE ACCOUNTADMIN;
    
    CREATE ROLE myrole;
    
    GRANT CREATE FAILOVER GROUP ON ACCOUNT
      TO ROLE myrole;
    
    Copy
  2. Erstellen Sie eine Failover-Gruppe im Quellkonto, und aktivieren Sie die Replikation in bestimmte Zielkonten:

    Bemerkung

    • Wenn Sie einer Replikations- oder Failover-Gruppe Datenbanken hinzufügen möchten, bei denen Datenbankreplikation und Failover zuvor mit ALTER DATABASE aktiviert worden war, befolgen Sie vor dem Hinzufügen der Datenbanken zu einer Gruppe die Anleitung unter Umstellen von Datenbankreplikation auf gruppenbasierte Replikation (unter diesem Thema).

    • Um eine Datenbank zu einer Failover-Gruppe hinzuzufügen, muss die aktive Rolle über die MONITOR-Berechtigung für die Datenbank verfügen. Weitere Informationen zu Berechtigungen für Datenbanken finden Sie unter Berechtigungen von Datenbanken (untere einem anderen Thema).

    USE ROLE myrole;
    
    CREATE FAILOVER GROUP myfg
      OBJECT_TYPES = USERS, ROLES, WAREHOUSES, RESOURCE MONITORS, DATABASES
      ALLOWED_DATABASES = db1, db2
      ALLOWED_ACCOUNTS = myorg.myaccount2, myorg.myaccount3
      REPLICATION_SCHEDULE = '10 MINUTE';
    
    Copy

Von Zielkonto ausführen

  1. Erstellen Sie eine Rolle im Zielkonto, und erteilen Sie dieser Rolle die Berechtigung CREATE FAILOVER GROUP. Der folgende Schritt ist optional:

    USE ROLE ACCOUNTADMIN;
    
    CREATE ROLE myrole;
    
    GRANT CREATE FAILOVER GROUP ON ACCOUNT
      TO ROLE myrole;
    
    Copy
  2. Erstellen Sie eine Failover-Gruppe im Zielkonto als Replikat der Failover-Gruppe im Quellkonto:

    Bemerkung

    Wenn im Zielkonto Kontoobjekte (z. B. Benutzer oder Rollen) vorhanden sind, die im Quellkonto nicht existieren, lesen Sie erst den Abschnitt Erstmalige Replikation von Benutzern und Rollen, bevor Sie eine sekundäre Gruppe erstellen.

    USE ROLE myrole;
    
    CREATE FAILOVER GROUP myfg
      AS REPLICA OF myorg.myaccount1.myfg;
    
    Copy
  3. Aktualisieren Sie die sekundäre Failover-Gruppe manuell. Dies ist ein optionaler Schritt. Wenn die primäre Failover-Gruppe mit einem Replikationsplan erstellt wird, wird beim Erstellen der sekundären Failover-Gruppe eine erste Aktualisierung der sekundären Failover-Gruppe automatisch ausgeführt.

    1. Erstellen Sie eine Rolle mit REPLICATE-Berechtigung für die Failover-Gruppe. Dieser Schritt ist optional.

      Führen Sie im Zielkonto unter Verwendung einer Rolle mit der Berechtigung OWNERSHIP für die Failover-Gruppe Folgendes aus:

      GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;
      
      Copy
    2. Führen Sie die Aktualisierungsanweisung unter Verwendung einer Rolle mit der Berechtigung REPLICATE aus:

      USE ROLE my_replication_role;
      
      ALTER FAILOVER GROUP myfg REFRESH;
      
      Copy

Replizieren von Kontoobjekten und Datenbanken

In den Anweisungen in diesem Abschnitt wird erläutert, wie Sie Ihre Konten für die Replikation vorbereiten, die Replikation bestimmter Objekte vom Quellkonto in das Zielkonto aktivieren und die Objekte im Zielkonto synchronisieren.

Wichtig

Bei Zielkonten ist standardmäßig weder Tri-Secret Secure noch private Konnektivität zum Snowflake-Dienst (z. B. AWS PrivateLink) aktiviert. Wenn Sie Tri-Secret Secure oder private Konnektivität zum Snowflake-Dienst aus Compliance-, Sicherheits- oder anderen Gründen benötigen, liegt es in Ihrer Verantwortung, diese Features im Zielkonto zu konfigurieren und zu aktivieren.

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');
Copy

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;
Copy

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.

Alle für Replikation aktivierten Konten anzeigen

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

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

SHOW REPLICATION ACCOUNTS;
Copy

Rückgabewerte:

+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| 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        |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+

Verwenden Sie auch die vollständige Liste der Regions-IDs.

Mitgliedschaft von Failover- und Replikationsgruppen anzeigen

Für Konto-, Datenbank- und Freigabeobjekte gibt es Einschränkungen hinsichtlich der Gruppenmitgliedschaft. Bevor Sie neue Gruppen erstellen oder Objekte zu bestehenden Gruppen hinzufügen, können Sie die Liste der bestehenden Failover-Gruppe und der Objekte in jeder Gruppe überprüfen.

Bemerkung

Nur ein Kontoadministrator (Benutzer mit der Rolle ACCOUNTADMIN) oder der Gruppeneigentümer (Rolle mit OWNERSHIP-Berechtigung für die Gruppe) kann die SQL-Anweisungen in diesem Abschnitt ausführen.

Anzeigen aller Failover-Gruppen, die mit dem aktuellen Konto verknüpft sind, sowie die Objekttypen in jeder Gruppe:

SHOW FAILOVER GROUPS;
Copy

Anzeigen aller Datenbanken in der Failover-Gruppe myfg:

SHOW DATABASES IN FAILOVER GROUP myfg;
Copy

Anzeigen aller Freigaben in der Failover-Gruppe myfg:

SHOW SHARES IN FAILOVER GROUP myfg;
Copy

Replikation von einem Quellkonto zum Zielkonto aktivieren

Sie können eine Replikations- oder Failover-Gruppe mit Snowsight oder SQL erstellen.

Bemerkung

Wenn Sie einer Replikations- oder Failover-Gruppe Datenbanken hinzufügen möchten, bei denen die Datenbankreplikation zuvor mit ALTER DATABASE aktiviert worden war, befolgen Sie vor dem Hinzufügen der Datenbanken zu einer Gruppe die Anleitung unter Umstellen von Datenbankreplikation auf gruppenbasierte Replikation (unter diesem Thema).

Replikations- oder Failover-Gruppe mit Snowsight erstellen

Bemerkung

Führen Sie die folgenden Schritte aus, um eine neue Replikations- oder Failover-Gruppe zu erstellen:

  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 + Add Group aus.

  4. Wählen Sie Target Account und dann Next aus.

  5. Geben Sie im Feld Group Name einen Namen für die Gruppe ein, der die folgenden Anforderungen erfüllen muss:

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

    • Der Bezeichner muss für alle Failover- und Replikationsgruppen in einem Konto eindeutig sein.

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

    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 zu Ihrer Gruppe hinzuzufügen.

  8. Wählen Sie die Registerkarte Replication Frequency aus.

  9. Wenn es sich bei dem Konto um die Business Critical Edition oder höher handelt, wird eine Failover-Gruppe standardmäßig erstellt. Sie können aber auch entscheiden, eine Replikationsgruppe zu erstellen. Um eine Replikationsgruppe zu erstellen, wählen Sie Advanced Options aus und deaktivieren dann die Option Enable Failover.

  10. Wählen Sie Start Replication aus, um die Replikationsgruppe zu erstellen.

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

Failover-Gruppe mit SQL erstellen

Erstellen Sie eine Failover-Gruppe mit den angegebenen Konto- und Datenbankobjekten im Quellkonto, und aktivieren Sie Replikation und Failover für eine Liste von Zielkonten. Weitere Informationen zur Syntax finden Sie unter CREATE FAILOVER GROUP.

Aktivieren Sie beispielsweise die Replikation von Benutzern, Rollen, Warehouses, Ressourcenmonitoren und der Datenbanken db1 und db2 vom Quellkonto in das Konto myaccount2 derselben Organisation. Konfigurieren den Replikationsplan so, dass myaccount2 alle 10 Minuten automatisch aktualisiert wird.

Führen Sie die folgende Anweisung auf dem Quellkonto aus:

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';
Copy

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;
Copy

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

Bemerkung

Wenn im Zielkonto Kontoobjekte (z. B. Benutzer oder Rollen) vorhanden sind, die im Quellkonto nicht existieren, lesen Sie erst den Abschnitt Erstmalige Replikation von Benutzern und Rollen, bevor Sie eine sekundäre Gruppe 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;
Copy

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.

Bemerkung

Wenn der Benutzer, der die Funktion im Zielkonto aufruft, im Quellkonto gelöscht wurde, schlägt die Aktualisierungsoperation fehl.

Rolle REPLICATE-Berechtigung für Failover-Gruppe erteilen – Optional

Um den Befehl zum Aktualisieren einer sekundären Replikations- oder Failover-Gruppe im Zielkonto auszuführen, müssen Sie eine Rolle mit REPLICATE-Berechtigung für die Failover-Gruppe verwenden. Die REPLICATE-Berechtigung wird derzeit nicht repliziert und muss für eine Failover-Gruppe (oder eine Replikationsgruppe) sowohl im Quell- als auch im Zielkonto erteilt werden.

Führen Sie die folgende Anweisung vom Quellkonto aus unter Verwendung einer Rolle mit der Berechtigung OWNERSHIP für die Gruppe aus:

GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;
Copy

Führen Sie die folgende Anweisung vom Zielkonto aus unter Verwendung einer Rolle mit der Berechtigung OWNERSHIP für die Gruppe aus:

GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;
Copy

Sekundäre Failover-Gruppe manuell aktualisieren

Um beispielsweise die Objekte in der Failover-Gruppe myfg zu aktualisieren, führen Sie die folgende Anweisung über das Zielkonto aus:

USE ROLE my_replication_role;

ALTER FAILOVER GROUP myfg REFRESH;
Copy

Globale IDs auf Objekte anwenden, die von Skripten in Zielkonten erstellt wurden

Wenn Sie Kontoobjekte wie Benutzer und Rollen in Ihrem Zielkonto nicht mittels Replikation (sondern z. B. mithilfe von Skripten) erstellt haben, haben diese Benutzer und Rollen standardmäßig keinen globalen Bezeichner. Bei der Aktualisierungsoperation werden globale Bezeichner verwendet, um diese Objekte mit denselben Objekten im Quellkonto zu synchronisieren.

Wenn ein Zielkonto vom Quellkonto aus aktualisiert wird, führt die Aktualisierungsoperation zum Löschen aller Kontoobjekte der Typen in der OBJECT_TYPES-Liste des Zielkontos, die keine globale ID haben. Die erstmalige Replikation von Benutzern und Rollen auf ein Zielkonto kann jedoch dazu führen, dass die erste Aktualisierungsoperation fehlschlägt. Weitere Informationen zu diesem Verhalten finden Sie unter Erstmalige Replikation von Benutzern und Rollen.

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.

Bemerkung

  • Das in diesem Abschnitt beschriebene Verhalten gilt nur, wenn diese Objekttypen das erste Mal in das Zielkonto repliziert werden.

  • Die folgenden Szenarios beschreiben die Replikation von USERS. Dieselbe Vorgehensweise gilt auch für die Replikation von ROLES.

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

Cloudspeicherzugriff für sekundäre Speicherintegrationen konfigurieren

Wenn Sie die Replikation der Speicherintegration aktivieren, müssen Sie nach der Replikation der Speicherintegration auf die Zielkonten zusätzliche Schritte ausführen. Die replizierte Integration hat eine eigene Entität für die Identitäts- und Zugriffsverwaltung (IAM), die sich von der Identitäts- und IAM-Entität der primären Integration unterscheidet. Daher müssen Sie die Berechtigungen Ihres Cloudanbieters aktualisieren, um der replizierten Integration Zugriff auf Ihren Cloudspeicher zu gewähren.

Sie müssen diese Vertrauensstellung für Zielkonten nur einmal konfigurieren.

Der Prozess ist ähnlich wie bei der Gewährung des Zugriffs im Quellkonto. Weitere Informationen dazu finden Sie auf den folgende Seiten:

Konfigurieren der automatischen Aktualisierung von Verzeichnistabellen in sekundären Stagingbereichen

Wenn Sie einen externen Stagingbereich mit Verzeichnistabelle replizieren und die automatische Aktualisierung für die primäre Verzeichnistabelle konfiguriert haben, müssen Sie die automatische Aktualisierung für die sekundäre Verzeichnistabelle konfigurieren.

Der Prozess ist ähnlich wie bei der Einrichtung der automatischen Aktualisierung in Ihrem Quellkonto. Weitere Informationen dazu finden Sie unter:

Wichtig

  • Nachdem Sie diese Konfigurationsschritte in Ihrem Zielkonto abgeschlossen haben, sollten Sie eine vollständige Aktualisierung Ihrer Verzeichnistabelle ausführen, um sicherzustellen, dass keine Benachrichtigungen übersehen wurden.

  • Bei Google Cloud Storage und Azure Blob Storage muss der Name der Benachrichtigungsintegration in jedem Zielkonto mit dem Namen der Benachrichtigungsintegration im Quellkonto übereinstimmen.

Konfigurieren von Benachrichtigungen für sekundäre Auto-Erfassungs-Pipes

Sie müssen zusätzliche Schritte ausführen, um vor dem Failover Cloudbenachrichtigungen für sekundäre Pipes zur automatischen Datenerfassung zu konfigurieren. In diesem Abschnitt wird erläutert, warum diese zusätzliche Konfiguration erforderlich ist und wie sie für jeden unterstützten Cloudanbieter ausgeführt werden kann.

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.

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:

Pipe replication for Azure

Folgen Sie den detaillierten Anweisungen unter Konfigurieren der Automatisierung mit Azure Event Grid, um ein Event Grid-Abonnement und eine Benachrichtigungsintegration zu konfigurieren.

Wichtig

Der Name der Benachrichtigungsintegration in jedem Zielkonto muss mit dem Namen der Benachrichtigungsintegration im Quellkonto übereinstimmen.

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:

Pipe replication for GCP

Eine ausführliche Anleitung zum Erstellen eines Pub/Sub-Abonnements und einer Benachrichtigungsintegration finden Sie unter Konfigurieren von automatischem Snowpipe mit GCS Pub/Sub.

Wichtig

Der Name der Benachrichtigungsintegration in jedem Zielkonto muss mit dem Namen der Benachrichtigungsintegration im Quellkonto übereinstimmen.

Aktualisieren des Remotedienstes für API-Integrationen

Wenn Sie die Replikation von API-Integrationen aktiviert haben, sind zusätzliche Schritte erforderlich, nachdem die API-Integration in das Zielkonto repliziert wurde. Die replizierte Integration hat eine eigene Entität für die Identitäts- und Zugriffsverwaltung (IAM), die sich von der Identitäts- und IAM-Entität der primären Integration unterscheidet. Daher müssen Sie die Berechtigungen für den Remotedienst aktualisieren, um den Zugriff auf replizierte Funktionen zu gewähren. Der Prozess ist ähnlich wie das Gewährung des Zugriffs auf die Funktionen des Primärkontos. Weitere Informationen dazu finden Sie unter:

Überwachen der Replikation

In diesem Abschnitt erfahren Sie, wie Sie Fortschritt, Verlauf und Kosten der Kontoreplikation überwachen können.

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.

Bemerkung

  • Snowsight listet die Replikations- und Failover-Gruppen auf, für die Ihre Rolle die Berechtigung MONITOR, OWNERSHIP oder REPLICATE hat.

  • Die Details zu Aktualisierungsoperationen sind nur für Benutzer mit der Rolle ACCOUNTADMIN oder der Berechtigung OWNERSHIP für die Gruppe verfügbar.

  • Sie müssen bei dem Zielkonto angemeldet sein, um die Details zu Aktualisierungsoperationen anzeigen zu können. Wenn Sie dies nicht sind, werden Sie aufgefordert, sich anzumelden.

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 Search icon (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ü Account icon (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:

Spalte

Beschreibung

Name

Name der Replikations- oder Failover-Gruppe.

Is Replicating

Gibt an, ob die Gruppe in ein Zielkonto oder aus einem Quellkonto repliziert wird.

Wenn diese Spalte verfügbare Ziele enthält, gibt es keine sekundären Replikations- oder Failover-Gruppen. Die Anzahl der verfügbaren Ziele gibt die Anzahl der Zielkonten an, in die die primäre Gruppe repliziert werden kann.

Status

Zeigt den Status der letzten Aktualisierungsoperation an.

Sie müssen bei dem Zielkonto angemeldet sein, um auf die Replikationsdetails zugreifen zu können. Wenn Sie nicht angemeldet sind, wählen Sie Sign in aus, um den Status der Aktualisierungsoperation für die sekundäre Gruppe anzuzeigen.

Replication Lag

Die Zeitdauer seit der letzten Aktualisierungsoperation. Dies ist die Zeitspanne, die die sekundäre Replikationsgruppe hinter der primären Replikationsgruppe zurückliegt.

Next Refresh

Datum und Uhrzeit der nächsten geplanten Aktualisierungsoperation.

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.

Fortschritt von Aktualisierungsoperationen mit Snowsight überwachen

Sie können den Status einer laufenden Aktualisierungsoperation und die Details historischer Aktualisierungsoperationen in Snowsight 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.

Weitere Informationen zur Detailansicht finden Sie im Abschnitt zum Replikationsverlauf in Snowsight.

Fortschritt von Aktualisierungsoperationen mit SQL überwachen

Um den Fortschritt der Aktualisierung einer Replikations- oder Failover-Gruppe zu überwachen, fragen Sie die Tabellenfunktion REPLICATION_GROUP_REFRESH_PROGRESS, REPLICATION_GROUP_REFRESH_PROGRESS_BY_JOB (in Snowflake Information Schema) ab.

Beispiel

Anzeigen des Fortschritts der letzten Aktualisierungsoperation für die Failover-Gruppe myfg:

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

Anzeigen des Replikationsverlaufs

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

Bemerkung

Sie können den Replikationsverlauf für die Replikations- und Failover-Gruppen anzeigen, für die Ihre Rolle die Berechtigung MONITOR, OWNERSHIP oder REPLICATE hat.

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.

Color coded replication phase and duration.

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

Replikationsverlauf mit SQL anzeigen

Um den Replikationsverlauf einer bestimmten Replikations- oder Failover-Gruppe innerhalb eines bestimmten Datumsbereichs anzuzeigen, führen Sie eine der folgenden Abfragen aus:

Beispiele

Abfragen der Information Schema-Tabellenfunktion REPLICATION_GROUP_REFRESH_HISTORY, um den Kontoreplikationsverlauf der Failover-Gruppe myfg in den letzten 7 Tagen anzuzeigen:

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';
Copy

Abfragen der Account Usage-Ansicht REPLICATION_GROUP_REFRESH_HISTORY, um den Kontoreplikationsverlauf im aktuellen Monat anzuzeigen:

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());
Copy

Replikationskosten überwachen

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

Beispiele

Abfragen der Tabellenfunktion REPLICATION_GROUP_USAGE_HISTORY, um die in den letzten 7 Tagen für die Kontoreplikation verbrauchten Credits anzuzeigen:

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())));
Copy

Abfragen der Account Usage-Ansicht REPLICATION_GROUP_USAGE_HISTORY, um die von der Replikations- oder Failover-Gruppe für die Kontoreplikationsverlauf im aktuellen Monat verbrauchten Credits anzuzeigen:

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());
Copy

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.

Beispiele

Abfragen der Account Usage-Ansichten

In den folgenden Beispielen werden die Kosten für die Datenbankreplikation einer Replikationsgruppe für die letzten 30 Tage berechnet.

  1. Abfragen der Account Usage-Ansicht REPLICATION_GROUP_REFRESH_HISTORY und Berechnen der Gesamtzahl der Bytes, die pro Datenbank repliziert wurden.

    Beispiel: Berechnen der Gesamtzahl der Bytes, die in den letzten 30 Tagen für Datenbanken der Replikationsgruppe myrg repliziert wurden:

    select sum(value:totalBytesToReplicate) as sum_database_bytes
    from snowflake.account_usage.replication_group_refresh_history rh,
        lateral flatten(input => rh.total_bytes:databases)
    where rh.replication_group_name = 'MYRG'
    and rh.start_time >= current_date - interval '30 days';
    
    Copy

    Beachten Sie die Ausgabe der Summe der Datenbankbytes:

    +--------------------+
    | SUM_DATABASE_BYTES |
    |--------------------|
    |              22016 |
    +--------------------+
    
    Copy
  2. Abfragen der Account Usage-Ansicht REPLICATION_GROUP_USAGE_HISTORY und Berechnen der Gesamtzahl der verbrauchten Credits und der Summe der Bytes, die für die Replikation übertragen wurden.

    Beispiel: Berechnen der Gesamtzahl der verbrauchten Credits und der Summe der Bytes, die in den letzten 30 Tagen für die Replikation der Replikationsgruppe myrg übertragen wurden:

    select sum(credits_used) as credits_used, SUM(bytes_transferred) as bytes_transferred
    from snowflake.account_usage.replication_group_usage_history
    where replication_group_name = 'MYRG'
    and start_time >= current_date - interval '30 days';
    
    Copy

    Beachten Sie die Ausgabe der Summe der verbrauchten Credits und der Summe der übertragenen Bytes:

    +--------------+-------------------+
    | CREDITS_USED | BYTES_TRANSFERRED |
    |--------------+-------------------|
    |  1.357923604 |             22013 |
    +--------------+-------------------+
    
    Copy
  3. Berechnen Sie die Replikationskosten für Datenbanken anhand der Werte der für Datenbanken übertragenen Bytes, der Summe der verbrauchten Credits und der Summe aller für die Replikation übertragenen Bytes aus den beiden vorherigen Schritten:

    (<database_bytes_transferred> / <bytes_transferred>) * <credits_used>

    Beispiel:

    (22016 / 22013) * 1.357923604 = 1.35810866)

Abfragen von Information Schema-Tabellenfunktionen

Um Werte für die Aktualisierungsoperationen der letzten 14 Tage zu erhalten, fragen Sie die entsprechenden Tabellenfunktionen des Information Schema ab.

  1. Abfragen der Tabellenfunktion REPLICATION_GROUP_REFRESH_HISTORY, um die Gesamtzahl der Bytes anzuzeigen, die zur Datenbankreplikation der Replikationsgruppe myrg kopiert wurden:

    select sum(value:totalBytesToReplicate)
      from table(information_schema.replication_group_refresh_history('myrg')) as rh,
      lateral flatten(input => total_bytes:databases)
      where rh.phase_name = 'COMPLETED'
      and rh.start_time >= current_date - interval '14 days';
    
    Copy
  2. Abfragen der Tabellenfunktion REPLICATION_GROUP_USAGE_HISTORY, um die Gesamtzahl der verbrauchten Credits und die Summe der Bytes anzuzeigen, die für die Replikation der Replikationsgruppe myrg übertragen wurden:

    select sum(credits_used), sum(bytes_transferred)
      from table(information_schema.replication_group_usage_history(
          date_range_start=>dateadd('day', -14, current_date()),
          replication_group_name => 'myrg'
      ));
    
    Copy

Vergleichen von Datensets in Primär- und Sekundärdatenbanken

Wenn Datenbankobjekte in einer Replikations- oder Failover-Gruppe repliziert werden, kann die Funktion HASH_AGG verwendet werden, um die Zeilen in einer zufälligen Menge von Tabellen einer Primär- und Sekundärdatenbank zu vergleichen und so die Datenkonsistenz zu überprüfen. Die HASH_AGG-Funktion gibt einen aggregierten, signierten 64-Bit-Hash-Wert für die (ungeordnete) Menge von Eingabezeilen zurück. Fragen Sie diese Funktion für alle oder eine zufällige Teilmenge von Tabellen einer sekundären Datenbank und in der primären Datenbank ab (ab dem Zeitstempel des Snapshots der primären Datenbank), und vergleichen Sie die Ausgabe.

Beispiel

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

Von Zielkonto ausführen

  1. Fragen Sie die Tabellenfunktion REPLICATION_GROUP_REFRESH_PROGRESS ab (in Snowflake Information Schema). Beachten Sie den primarySnapshotTimestamp in der Spalte DETAILS für die Phase PRIMARY_UPLOADING_METADATA. Dies ist der Zeitstempel für den neuesten Snapshot der Primärdatenbank.

    SELECT PARSE_JSON(details)['primarySnapshotTimestamp']
      FROM TABLE(information_schema.replication_group_refresh_progress('myfg'))
      WHERE PHASE_NAME = 'PRIMARY_UPLOADING_METADATA';
    
    Copy
  2. Fragen Sie die Funktion HASH_AGG für eine angegebene Tabelle der Sekundärdatenbank ab. Die folgende Abfrage gibt einen Hashwert für alle Zeilen der Tabelle mytable zurück:

    SELECT HASH_AGG( * ) FROM mytable;
    
    Copy

Von Quellkonto ausführen

  1. Fragen Sie die Funktion HASH_AGG für dieselbe Tabelle der Primärdatenbank ab. Geben Sie mithilfe von Time Travel den Zeitstempel an, zu dem der letzte Snapshot der sekundären Datenbank erstellt wurde:

    SELECT HASH_AGG( * ) FROM mytable AT(TIMESTAMP => '<primarySnapshotTimestamp>'::TIMESTAMP);
    
    Copy
  2. Vergleichen Sie die Ergebnisse der beiden Abfragen. Die Ausgabe sollte identisch sein.

Ändern einer Replikations- oder Failover-Gruppe

Sie können den Namen, die enthaltenen Objekte und den Replikationsplan einer Replikations- oder Failover-Gruppe mit Snowsight oder SQL bearbeiten.

Replikations- oder Failover-Gruppe mit Snowsight ändern

Bemerkung

Nur Kontoadministratoren können eine Replikations- oder Failover-Gruppe mit Snowsight bearbeiten (siehe Einschränkungen bei der Verwendung von Snowsight für die Replikationskonfiguration).

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.

  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.

Löschen einer sekundären Replikations- oder Failover-Gruppe

Sie können eine sekundäre Replikations- oder Failover-Gruppe mit den Befehlen DROP REPLICATION GROUP bzw. DROP FAILOVER GROUP löschen. Nur der Eigentümer der Replikations- oder Failover-Gruppe (d. h. die Rolle mit OWNERSHIP-Berechtigung für die Gruppe) kann die Gruppe löschen.

Um eine sekundäre Replikations- oder Failover-Gruppe mit Snowsight zu löschen, müssen Sie die Gruppe im Quellkonto löschen. Siehe Replikations- oder Failover-Gruppe mit Snowsight löschen.

Löschen einer primären Replikations- oder Failover-Gruppe

Sie können eine primäre Replikations- oder Failover-Gruppe mit Snowsight oder SQLlöschen. Wenn Sie eine primäre Gruppe mit SQL löschen möchten, müssen Sie zuerst alle sekundären Gruppen löschen. Siehe Löschen einer sekundären Replikations- oder Failover-Gruppe.

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

Bemerkung

Nur Kontoadministratoren können eine Replikations- oder Failover-Gruppe mit Snowsight löschen (siehe Einschränkungen bei der Verwendung von Snowsight für die Replikationskonfiguration).

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.

Probleme beim Erstellen und Bearbeiten von Replikationsgruppen in Snowsight beheben

Die folgenden Szenarios können Ihnen helfen, Probleme zu beheben, die beim Erstellen oder Bearbeiten von Replikations- oder Failover-Gruppen in Snowsight auftreten können.

Eine Datenbank kann nicht zu einer Gruppe hinzugefügt werden

Fehler

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

Ursache

Eine Datenbank kann nur in einer einzigen Replikations- oder Failover-Gruppe sein. Eine der Datenbanken, die Sie für die Gruppe ausgewählt haben, ist bereits in einer anderen Replikations- oder Failover-Gruppe enthalten.

Lösung

Wählen Sie Select Databases aus, und heben Sie die Markierung aller Datenbanken auf, die bereits in einer anderen Gruppe enthalten sind.

Fehler

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

Ursache

Die Datenbank, die Sie zu einer Replikations- oder Failover-Gruppe hinzufügen möchten, war zuvor für die Datenbankreplikation konfiguriert.

Lösung

Deaktivieren Sie die Datenbankreplikation für die Datenbank. Siehe Umstellen von Datenbankreplikation auf gruppenbasierte Replikation.

Eine Freigabe kann nicht zu einer Gruppe hinzugefügt werden

Fehler

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

Ursache

Eine Freigabe kann nur in einer einzigen Replikations- oder Failover-Gruppe sein. Eine der Freigaben, die Sie für die Gruppe ausgewählt haben, ist bereits in einer anderen Replikations- oder Failover-Gruppe enthalten.

Lösung

Wählen Sie Select Objects aus, und heben Sie die Markierung aller Freigaben auf, die bereits in einer anderen Gruppe enthalten sind.

Einschränkungen bei der Verwendung von Snowsight für die Replikationskonfiguration

  • Nur ein Benutzer mit der Rolle ACCOUNTADMIN kann in Snowsight eine Replikations- oder Failover-Gruppe erstellen. Benutzer mit einer Rolle, der die Berechtigung CREATE REPLICATION GROUP oder CREATE FAILOVER GROUP zugewiesen ist, kann mit den entsprechenden SQL-Befehlen eine Gruppe erstellen.

  • Nur ein Benutzer mit der Rolle ACCOUNTADMIN kann eine Replikations- oder Failover-Gruppe in Snowsight bearbeiten oder löschen. Ein Benutzer mit einer Rolle, der die Berechtigung OWNERSHIP für eine Replikations- oder Failover-Gruppe zugewiesen ist, kann Gruppen mit den entsprechenden SQL-Befehlen bearbeiten und löschen.