Replizieren von Kontoobjekten¶
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.
Unter diesem Thema:
Unterstützung von Replikation und Failover/Failback in den Regionen
Umstellen von Datenbankreplikation auf gruppenbasierte Replikation
Replizieren von Kontoobjekten und Datenbanken
Voraussetzung: Aktivieren Sie die Replikation für Konten der Organisation
Schritt 1: Rolle mit CREATE FAILOVER GROUP-Berechtigung im Quellkonto erstellen – Optional
Schritt 2: Primäre Failover-Gruppe in einem Quellkonto erstellen
Schritt 3: Rolle mit CREATE FAILOVER GROUP-Berechtigung Privileg im Zielkonto erstellen – Optional
Manuelles Aktualisieren einer sekundären Failover-Gruppe in einem Zielkonto
Vergleichen von Datasets in primären und sekundären Datenbanken
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ähige 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.
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¶
Erstellen Sie eine Rolle, und erteilen Sie dieser Rolle die Berechtigung CREATE FAILOVER GROUP. Der folgende Schritt ist optional:
-- Execute the following SQL statements using the ACCOUNTADMIN role: USE ROLE ACCOUNTADMIN; CREATE ROLE myrole; GRANT CREATE FAILOVER GROUP ON ACCOUNT TO ROLE myrole;
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 Datenbankberechtigungen (untere einem anderen Thema).
USE ROLE myrole; -- Execute the following SQL statement using a role with the CREATE FAILOVER GROUP privilege: 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';
Achtung
Wenn Kontoobjekte (z. B. Benutzer oder Rollen), die Sie während der Replikation nicht löschen möchten, im Zielkonto vorhanden sind, geben Sie beim Erstellen einer Replikations- oder Failover-Gruppe keinen Parameter in
REPLICATION_SCHEDULE
an. Weitere Details dazu finden Sie unter Schritt 5: Globale IDs auf Objekte anwenden, die von Skripten in Zielkonten erstellt wurden – Optional.
Von Zielkonto ausführen¶
Erstellen Sie eine Rolle im Zielkonto, und erteilen Sie dieser Rolle die Berechtigung CREATE FAILOVER GROUP. Der folgende Schritt ist optional:
-- Execute the following SQL statements using the ACCOUNTADMIN role: USE ROLE ACCOUNTADMIN; CREATE ROLE myrole; GRANT CREATE FAILOVER GROUP ON ACCOUNT TO ROLE myrole;
Erstellen Sie eine Failover-Gruppe im Zielkonto als Replikat der Failover-Gruppe im Quellkonto:
USE ROLE myrole; -- Execute the following SQL statement using a role with the CREATE FAILOVER GROUP privilege: CREATE FAILOVER GROUP myfg AS REPLICA OF myorg.myaccount1.myfg;
Wenden Sie globale IDs auf die Objekte an. Dies ist ein optionaler Schritt für alle Kontoobjekte, die nicht über die Replikation erstellt wurden.
-- Execute the following SQL statements using the ACCOUNTADMIN role: SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('myfg');
Achtung
Dieser Schritt muss ausgeführt werden, wenn im Zielkonto Kontoobjekte (wie z. B. Benutzer) vorhanden sind, die Sie während der Replikation nicht löschen möchten. Wird dieser Schritt übersprungen, kann dies zum Verlust von Benutzer-Arbeitsblättern oder der Berechtigungszuweisungen zu Rollen für Objekte (z. B. für Freigaben) führen. Weitere Details dazu finden Sie unter Schritt 5: Globale IDs auf Objekte anwenden, die von Skripten in Zielkonten erstellt wurden – Optional.
Sekundäre Gruppe manuelle aktualisieren¶
Weitere Informationen zum manuellen Aktualisieren einer sekundären Failover-Gruppe im Zielkonto finden Sie unter Manuelles Aktualisieren einer sekundären Failover-Gruppe in einem Zielkonto (unter diesem Thema).
Bemerkung
Als Best Practice empfiehlt Snowflake das Erstellen eines Zeitplans für automatische Aktualisierungen unter Verwendung des Parameters REPLICATION_SCHEDULE. Weitere Informationen dazu finden Sie unter Replikationsplan (unter diesem Thema).
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.
-- Assume the ORGADMIN role
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.
Vorschau für das Aktivieren der Stream- und Aufgabenreplikation – Optional¶
Um Vorschau für die Streamreplikation und die Aufgabenreplikation für ein Konto, eine Datenbank, eine Replikations- oder Failover-Gruppe zu aktivieren, setzen Sie den Parameter ENABLE_STREAM_TASK_REPLICATION für das Quellkonto oder das Primärobjekt auf true
.
Beispiele¶
Die folgenden Beispiele müssen im Quellkonto ausgeführt werden.
Aktivieren der Stream- und Aufgabenreplikation für die Datenbank mydb
:
alter database mydb set ENABLE_STREAM_TASK_REPLICATION = true;
Aktivieren der Stream- und Aufgabenreplikation für die Replikationsgruppe myrg
:
alter replication group myrg set ENABLE_STREAM_TASK_REPLICATION = true;
Aktivieren der Stream- und Aufgabenreplikation für Konto myaccount
in Organisation myorg
:
alter account myorg.myaccount set ENABLE_STREAM_TASK_REPLICATION = true;
Bemerkung
Der Parameter kann nicht für Datenbanken festgelegt werden, die in einer Replikations- oder Failover-Gruppe enthalten sind.
Wenn der Parameter explizit auf ein Datenbankobjekt gesetzt ist, das nicht in einer Replikations- oder Failover-Gruppe enthalten ist, müssen Sie den Parameter entfernen, bevor Sie ihn zu einer Replikations- oder Failover-Gruppe hinzufügen. Andernfalls schlägt die Replikationsoperation fehl.
Die für Datenbank, Replikationsgruppe oder Failover-Gruppe festgelegten Parameter überschreiben die für das Konto festgelegten Parameter. Weitere Informationen dazu finden Sie unter Parameter Hierarchy and Types und Object Parameters.
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.
-- Execute the following SQL statements using the ACCOUNTADMIN role:
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.
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.
-- Execute the following SQL statements using the ACCOUNTADMIN role:
SHOW REPLICATION ACCOUNTS;
+------------------------+-------------------------+--------------+-----------------+-----------------+-------------------+
| snowflake_region | created_on | account_name | account_locator | comment | organization_name |
+------------------------+-------------------------+--------------+-----------------+-----------------+-------------------+
| AWS_US_WEST_2 | 2020-07-15 21:59:25.455 | myaccount1 | myacctlocator1 | | myorg |
+------------------------+-------------------------+--------------+-----------------+-----------------+-------------------+
| AWS_US_EAST_1 | 2020-07-23 14:12:23.573 | myaccount2 | myacctlocator2 | | myorg |
+------------------------+-------------------------+--------------+-----------------+-----------------+-------------------+
| AWS_US_EAST_2 | 2020-07-25 19:25:04.412 | myaccount3 | myacctlocator3 | | myorg |
+------------------------+-------------------------+--------------+-----------------+-----------------+-------------------+
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;
Anzeigen aller Datenbanken in der Failover-Gruppe myfg
:
SHOW DATABASES IN FAILOVER GROUP myfg;
Anzeigen aller Freigaben in der Failover-Gruppe myfg
:
SHOW SHARES IN FAILOVER GROUP myfg;
Replikation von Konto- und Datenbankobjekten von einem Quellkonto zum Zielkonto aktivieren¶
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.
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).
Auf dem Quellkonto ausführen:
use role myrole;
-- Execute the following SQL statement using a role with the CREATE FAILOVER GROUP privilege:
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';
Achtung
Wenn Kontoobjekte (z. B. Benutzer oder Rollen), die Sie während der Replikation nicht löschen möchten, im Zielkonto vorhanden sind, geben Sie beim Erstellen einer Replikations- oder Failover-Gruppe keinen Parameter in REPLICATION_SCHEDULE
an. Weitere Details dazu finden Sie unter Schritt 5: Globale IDs auf Objekte anwenden, die von Skripten in Zielkonten erstellt wurden – Optional.
Schritt 3: Rolle mit CREATE FAILOVER GROUP-Berechtigung Privileg 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.
-- Execute the following SQL statements using the ACCOUNTADMIN role:
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;
-- Execute the following SQL statement using a role with the CREATE FAILOVER GROUP privilege:
CREATE FAILOVER GROUP myfg
AS REPLICA OF myorg.myaccount1.myfg;
Schritt 5: Globale IDs auf Objekte anwenden, die von Skripten in Zielkonten erstellt wurden – Optional¶
Achtung
Dieser Schritt muss ausgeführt werden, wenn im Zielkonto Kontoobjekte (wie z. B. Benutzer) vorhanden sind, die Sie während der Replikation nicht löschen möchten. Wird dieser Schritt übersprungen, kann dies zum Verlust von Benutzer-Arbeitsblättern oder der Berechtigungszuweisungen zu Rollen für Objekte (z. B. für Freigaben) führen.
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 (z. B. users
oder roles
) des Zielkontos, die keinen globalen Bezeichner haben.
Replikations- oder Failover-Gruppen ohne Replikationsplan erstellen¶
Wenn eine sekundäre Replikations- oder Failover-Gruppe als Replikat einer primären Replikations- oder Failover-Gruppe mit einem Replikationsplan erstellt wird, wird beim Erstellen der sekundären Replikations- oder Failover-Gruppe automatisch eine erste Aktualisierung der sekundären Gruppe ausgeführt. Um dies zu verhindern, bevor Sie die folgenden Anweisungen ausführen können, erstellen Sie die primäre Replikations- oder Failover-Gruppe ohne Festlegen des Parameters REPLICATION_SCHEDULE
.
Nachdem die sekundäre Gruppe im Zielkonto erstellt wurde, fügen Sie mit der Funktion SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME globale Bezeichner zu Kontoobjekten im Zielkonto hinzu. Kontoobjekte, die nur im Zielkonto vorhanden sind, müssen vor dem Aufrufen dieser Funktion manuell im Quellkonto repliziert werden.
Nachdem Sie den Objekten im Zielkonto globale Bezeichner zugewiesen oder sie im Quellkonto manuell neu erstellt haben, legen Sie mit dem Befehl ALTER REPLICATION GROUP oder ALTER FAILOVER GROUP den Replikationsplan für die primäre Replikations- oder Failover-Gruppe fest.
SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME() zum Anwenden von globalen IDs verwenden¶
Bemerkung
Globale Bezeichner werden nur zu Kontoobjekten hinzugefügt, die in einer Replikations- oder Failover-Gruppe für die folgenden Objekttypen enthalten sind:
RESOURCE_MONITOR
ROLE
USER
WAREHOUSE
Wenden Sie globale Bezeichner auf Kontoobjekte im Zielkonto an, die in der Liste object_types
für die Failover-Gruppe myfg
enthalten sind:
-- Execute the following SQL statements using the ACCOUNTADMIN role:
SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('myfg');
Remotedienst für API-Integrationen aktualisieren¶
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:
Amazon Web Services Vertrauensstellungen zwischen Snowflake und der neuen IAM-Rolle einrichten
Google Cloud Platform: GCP-Sicherheitsrichtlinie für Proxydienst erstellen
Microsoft Azure:
Schritt 1. API-Integration für Azure verknüpfen
Schritt 2. validate-JWT-Richtlinie erstellen
Manuelles Aktualisieren einer sekundären Failover-Gruppe in einem Zielkonto¶
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¶
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.
Von Quellkonto ausführen:
-- Execute the following SQL statements using a role with the OWNERSHIP privilege on the group: GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;Von Zielkonto ausführen:
-- Execute the following SQL statements using a role with the OWNERSHIP privilege on the group: GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;
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; -- Execute the following SQL statements using a role with the REPLICATE privilege: ALTER FAILOVER GROUP myfg REFRESH;
Überwachen der Replikation¶
In diesem Abschnitt erfahren Sie, wie Sie Fortschritt, Verlauf und Kosten der Kontoreplikation überwachen können.
Fortschritt der Aktualisierung einer Replikations- oder Failover-Gruppe ü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'));
Replikationsverlauf¶
Um den Replikationsverlauf einer bestimmten Replikations- oder Failover-Gruppe innerhalb eines bestimmten Datumsbereichs anzuzeigen, führen Sie eine der folgenden Abfragen aus:
Tabellenfunktion REPLICATION_GROUP_REFRESH_HISTORY (in Snowflake Information Schema)
Ansicht REPLICATION_GROUP_REFRESH_HISTORY (in Account Usage)
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';
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());
Replikationskosten überwachen¶
Um die Credit-Nutzung für die Replikation zu überwachen, können Sie folgende Abfragen ausführen:
Tabellenfunktion REPLICATION_GROUP_USAGE_HISTORY (in Snowflake Information Schema)
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())));
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());
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.
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';
Beachten Sie die Ausgabe der Summe der Datenbankbytes:
+--------------------+ | SUM_DATABASE_BYTES | |--------------------| | 22016 | +--------------------+
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';
Beachten Sie die Ausgabe der Summe der verbrauchten Credits und der Summe der übertragenen Bytes:
+--------------+-------------------+ | CREDITS_USED | BYTES_TRANSFERRED | |--------------+-------------------| | 1.357923604 | 22013 | +--------------+-------------------+
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.
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';
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' ));
Vergleichen von Datasets in primären und sekundären Datenbanken¶
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¶
Fragen Sie die Tabellenfunktion REPLICATION_GROUP_REFRESH_PROGRESS ab (in Snowflake Information Schema). Beachten Sie den
primarySnapshotTimestamp
in der SpalteDETAILS
für die PhasePRIMARY_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';
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;
Von Quellkonto ausführen¶
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);
Vergleichen Sie die Ergebnisse der beiden Abfragen. Die Ausgabe sollte identisch sein.