Replizieren von Datenbanken über mehrere Konten¶
Unter diesem Thema werden die Schritte beschrieben, die zum Replizieren von Datenbanken über mehrere Snowflake-Konten hinweg und zum Synchronisieren der Datenbankobjekte und gespeicherten Daten erforderlich sind. Die Datenbankreplikation kann über Snowflake-Konten in derselben oder in verschiedenen Regionen erfolgen.
Bemerkung
Snowflake empfiehlt die Verwendung des Features Kontoreplikation zum Replizieren von Datenbanken. Replikations- und Failover-Gruppen ermöglichen die Replikation von mehreren Datenbanken und anderen Kontoobjekten mit zeitpunktbezogener Konsistenz für Objekte in der Gruppe. Eine vollständige Liste der Feature-Verfügbarkeit und der unterstützten Objekte finden Sie unter Einführung in Replikation und Failover über mehrere Konten.
Unter diesem Thema:
Unterstützung von Datenbankreplikation und Failover/Failback in den Regionen¶
Alle Snowflake-Regionen auf Amazon Web Services, Google Cloud Platform und Microsoft Azure unterstützen Datenbankreplikation und Failover/Failback.
Beachten Sie, dass Konten Datenbanken zwischen Regionsgruppen (z. B. zwischen Virtual Private Snowflake (VPS) und Regionen mit mehreren Mandanten) replizieren können, wodurch das Data Sharing und die Migration von Konten zwischen diesen Regionen vereinfacht werden. Diese Fähigkeit ist standardmäßig deaktiviert. Sie können sich an den Snowflake-Support wenden, um den Zugriff zu aktivieren.
Weboberfläche für Datenbankreplikation und Failover/Failback¶
Achtung
Das Verwalten und Überwachen von Replikation und Failover/Failback über Snowsight und die klassische Konsole ist nur bei Konten verfügbar, die private Konnektivität nutzen.
Informationen zu allen anderen Konten finden Sie unter Replikation mit Snowsight überwachen und Replizieren von Kontoobjekten und Datenbanken.
Kontoadministratoren (Benutzer mit der Rolle ACCOUNTADMIN) können Replikations- und Failover/Failback-Aktionen über Snowsight oder die klassischen Weboberfläche verwalten.
Snowsight¶
- Navigation:
Data » Databases
Primärdatenbanken verwalten¶
Achtung
Nur verfügbar bei Konten mit privater Konnektivität. Informationen zu allen anderen Konten finden Sie unter Replikation mit Snowsight überwachen und Replizieren von Kontoobjekten und Datenbanken.
Melden Sie sich über Snowsight bei einem Snowflake-Konto an, das eine Primärdatenbank enthält.
Wählen Sie das Dropdown-Menü oben links aus (neben Ihrem Anmeldenamen) » Switch Role »
ACCOUNTADMIN
.Wählen Sie im linken Navigationsbereich Data » Databases aus. Wählen Sie im Datenbank-Objekt-Explorer eine Primärdatenbank aus. Die Datenbank-Detailseite wird geöffnet.
Wenn Sie nur Datenbanken anzeigen möchten, die für die Replikation aktiviert wurden, können Sie alternativ den Filter Replication Status » Primary verwenden, um die Primärdatenbank im Konto aufzulisten. Wählen Sie eine Datenbank in der Liste aus, um die zugehörige Detailseite zu öffnen.
Bemerkung
Der Filter Replication Status ist nur verfügbar, wenn ein Konto ein Quell- oder Zielkonto für die Datenbankreplikation ist.
Wählen Sie » Enable Replication aus. Das Dialogfenster Enable replication wird geöffnet.
Wählen Sie die Aktion aus, die Sie ausführen möchten:
Aktivieren des Failover. Außerdem erfordert dieses Feature die Business Critical Edition (oder höher).
Erstellen einer Sekundärdatenbank in einem oder mehreren Zielkonten.
Wenn in einem anderen Konto eine Primärdatenbank für die Replikation in das aktuelle Konto aktiviert ist, können Sie eine Sekundärdatenbank im aktuellen Konto erstellen. Um weitere Zielkonten hinzuzufügen, aktualisieren Sie im Quellkonto mit dem Befehl ALTER DATABASE die Primärdatenbank.
Aktualisieren jeder Sekundärdatenbank einmal, nachdem sie erstellt wurde.
Aktivieren Sie für jedes Zielkonto dieser Datenbank die Optionen zum Erstellen einer Sekundärdatenbank und zum Aktualisieren der Datenbank.
Melden Sie sich beim Zielkonto als Benutzer an, dem zuvor die Rolle ACCOUNTADMIN in diesem Konto zugewiesen wurde.
Snowflake führt die angeforderten Aktionen aus und zeigt einen Erfolgsdialog an.
Verwalten Sie die Replikation für diese Datenbank auf der Registerkarte Replication der Datenbankdetails.
Sekundärdatenbanken verwalten¶
Achtung
Nur verfügbar bei Konten mit privater Konnektivität. Informationen zu allen anderen Konten finden Sie unter Replikation mit Snowsight überwachen und Replizieren von Kontoobjekten und Datenbanken.
Melden Sie sich über Snowsight bei einem Snowflake-Konto an, das eine Sekundärdatenbank enthält.
Wählen Sie das Dropdown-Menü oben links aus (neben Ihrem Anmeldenamen) » Switch Role »
ACCOUNTADMIN
.Wählen Sie im linken Navigationsbereich Data » Databases aus.
Die folgenden Aktionen sind über die Aktionsschaltfläche (…) in der oberen rechten Ecke der Seite verfügbar:
Sekundärdatenbank erstellen.
Bemerkung
Diese Option ist nur verfügbar, wenn ein Konto ein Quell- oder Zielkonto für die Datenbankreplikation ist.
Wenn in einem anderen Konto eine Primärdatenbank für die Replikation in das aktuelle Konto aktiviert ist, können Sie eine Sekundärdatenbank im aktuellen Konto erstellen. Um weitere Zielkonten hinzuzufügen, aktualisieren Sie im Quellkonto mit dem Befehl ALTER DATABASE die Primärdatenbank.
Wählen Sie im Datenbankobjekt-Explorer eine Sekundärdatenbank aus. Die Datenbank-Detailseite wird geöffnet.
Wählen Sie die Registerkarte Replication aus.
Die folgenden Aktionen sind über die Aktionsschaltfläche (…) in der oberen rechten Ecke der Seite verfügbar:
Heraufstufen der sekundären Datenbank zur primären Datenbank. Außerdem erfordert dieses Feature die Business Critical Edition (oder höher).
Bemerkung
Um eine Sekundärdatenbank zur Primärdatenbank heraufzustufen, muss für die Primärdatenbank das Failover für das Zielkonto, in dem sich die Sekundärdatenbank befindet, aktiviert sein.
Wenn diese Option nicht verfügbar ist, können Sie den Befehl ALTER DATABASE im Quellkonto verwenden, um das Failover für die Primärdatenbank auf dem Zielkonto zu aktivieren. Weitere Informationen dazu finden Sie unter Schritt 3: Aktivieren des Failovers für eine Primärdatenbank.
Aktualisieren Sie die Sekundärdatenbank.
Kopieren Sie eine Vorlage, um eine Aufgabe zu erstellen, mit der die Sekundärdatenbank nach einem Zeitplan aktualisiert wird. Fügen Sie die Vorlage in ein Snowsight-Arbeitsblatt ein, und bearbeiten Sie sie, um den gewünschten Zeitplan festzulegen.
Klassische Konsole¶
Achtung
Nur verfügbar bei Konten mit privater Konnektivität. Informationen zu allen anderen Konten finden Sie unter Replikation mit Snowsight überwachen und Replizieren von Kontoobjekten und Datenbanken.
Die meisten Aktionen zum Konfigurieren und Verwalten der Datenbankreplikation können Sie auf der klassischen Weboberfläche über den Bereich Replication der Registerkarte Databases ausführen, einschließlich der folgenden Aktionen:
Aktivieren der Replikation für eine lokale Datenbank. Damit wird eine Datenbank zur Primärdatenbank heraufgestuft.
Aktivieren des Failover für eine Primärdatenbank (Business Critical Edition-Konten oder höher)
Aktualisieren einer sekundären Datenbank entweder einmal (manuell) oder wiederholt (nach Zeitplan unter Verwendung einer Aufgabe)
Heraufstufen einer Sekundärdatenbank als Primärdatenbank (Business Critical Edition-Konten oder höher).
Bemerkung
Damit eine Sekundärdatenbank als Primärdatenbank fungieren kann, muss für die Primärdatenbank das Failover des Zielkontos, in dem sich die Sekundärdatenbank befindet, aktiviert sein.
Wenn diese Option nicht verfügbar ist:
Melden Sie sich bei dem Quellkonto mit der Primärdatenbank an.
Wählen Sie im Bereich Databases die Option Replication aus.
Wählen Sie die Registerkarte Primary aus, um die Primärdatenbanken aufzulisten. Wählen Sie die Zeile mit der Primärdatenbank aus.
Suchen Sie das Zielkonto, für das Sie das Failover aktivieren möchten, und wählen Sie Failover aus.
Deaktivieren der Replikation und/oder von Failover einer Primärdatenbank
Replizieren einer Datenbank in ein anderes Konto¶
In den Anweisungen in diesem Abschnitt wird erläutert, wie Sie Ihre Konten für die Replikation vorbereiten, eine lokale Datenbank als Primärdatenbank heraufstufen, die erstmalige Replikation dieser Primärdatenbank auf ein anderes Konto durchführen und die Aktualisierung der Sekundärdatenbank planen.
Wichtig
Für Zielkonten ist standardmäßig weder Tri-Secret Secure oder 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 die Quell- und Zielkonten aktivieren, bevor eine Datenbank repliziert wird. Eine detaillierte Anleitung finden Sie unter Voraussetzung: Aktivieren Sie die Replikation für Konten der Organisation.
Datenbankreplikation und Failover sowie Aktualisieren von Sekundärdatenbanken aktivieren¶
Bemerkung
Wenn nicht anders angegeben muss die SQL-Anweisung in diesem Abschnitt von Kontoadministratoren (Benutzer mit der Rolle ACCOUNTADMIN) ausgeführt werden.
Schritt 1: Anzeigen aller Konten Ihrer Organisation¶
Rufen Sie die Liste der Konten in Ihrer Organisation anzuzeigen, in der die Replikation aktiviert wurde. Jede in diesen Konten vorhandene permanente oder transiente Datenbank kann so geändert werden, dass sie als Primärdatenbank dient. Replikate einer Primärdatenbank (d. h. Sekundärdatenbanken) können nur in diesen Konten erstellt werden.
Fragen Sie SHOW REPLICATION ACCOUNTS ab, um die Liste der Konten in Ihrer Organisation anzuzeigen.
SHOW REPLICATION ACCOUNTS;
+------------------+---------------------------------+---------------+------------------+---------+-------------------+
| snowflake_region | created_on | account_name | account_locator | comment | organization_name |
|------------------+---------------------------------+---------------+------------------+---------+-------------------|
| AWS_US_WEST_2 | 2018-11-19 16:11:12.720 -0700 | ACCOUNT1 | MYACCOUNT1 | | MYORG |
| AWS_US_EAST_1 | 2019-06-02 14:12:23.192 -0700 | ACCOUNT2 | MYACCOUNT2 | | MYORG |
+------------------+---------------------------------+---------------+------------------+---------+-------------------+
Verwenden Sie auch die vollständige Liste der Regions-IDs.
Schritt 2: Heraufstufen einer lokalen Datenbank zur Verwendung als Primärdatenbank¶
Ändern Sie eine vorhandene permanente oder transiente Datenbank, um sie als Primärdatenbank zu verwenden. Verwenden Sie dafür die Anweisung ALTER DATABASE … ENABLE REPLICATION TO ACCOUNTS. Stellen Sie eine durch Kommas getrennte Liste der Konten Ihrer Organisation bereit, in denen ein Replikat dieser Datenbank (d. h. eine Sekundärdatenbank) gespeichert werden kann, sodass Benutzer in diesen Konten Objekte der Sekundärdatenbank abfragen können.
Beispiel¶
Heraufstufen der lokalen Datenbank mydb1
(in Konto account1
) zur Primärdatenbank und Festlegen, dass die Konten account2
und account3
jeweils ein Replikat dieser Datenbank speichern können:
ALTER DATABASE mydb1 ENABLE REPLICATION TO ACCOUNTS myorg.account2, myorg.account3;
Schritt 3: Aktivieren des Failovers für eine Primärdatenbank¶
Bemerkung
Failover/Failback erfordert Business Critical (oder höher). Wenden Sie sich für ein Upgrade direkt an den Snowflake-Support.
Aktivieren Sie das Failover einer Primärdatenbank für ein oder mehrere Konten Ihrer Organisation mithilfe einer Anweisung ALTER DATABASE … ENABLE FAILOVER TO ACCOUNTS. Das Replikat dieser Primärdatenbank in einem der Konten (d. h. eine Sekundärdatenbank) kann heraufgestuft werden, um als Primärdatenbank zu dienen.
Beachten Sie, dass das Aktivieren des Failovers für eine Primärdatenbank entweder vor oder nach dem Erstellen des Replikats der Primärdatenbank in einem angegebenen Konto erfolgen kann.
Beispiel¶
Aktivieren Sie das Failover der Primärdatenbank mydb1
in die Konten account2
und account3
.
-- Executed from primary account
ALTER DATABASE mydb1 ENABLE FAILOVER TO ACCOUNTS myorg.account2, myorg.account3;
Schritt 4: Erstellen einer Sekundärdatenbank¶
Erstellen Sie ein Replikat einer vorhandenen Primärdatenbank entweder in demselben Konto, in dem die Primärdatenbank gespeichert ist, oder in einem anderen Konto (in derselben oder in einer anderen Region). Beachten Sie, dass Sie eine Sekundärdatenbank nur in einem Konto erstellen können, das in der Anweisung ALTER DATABASE … ENABLE REPLICATION TO ACCOUNTS in Schritt 2: Heraufstufen einer lokalen Datenbank zur Verwendung als Primärdatenbank angegeben ist.
Bemerkung
Replikationsbefehle (z. B. das Heraufstufen einer Datenbank zur Primärdatenbank in einem Quellkonto) lösen in der Regel regionsübergreifende Operationen aus und können einige Sekunden dauern, bis sie wirksam werden. Wenn Sie z. B. eine Datenbank programmgesteuert zur Primärdatenbank in einem Quellkonto heraufstufen und eine Sekundärdatenbank in einem Zielkonto erstellen, kann es einige Sekunden dauern, bis Sie die Sekundärdatenbank erstellen können.
Führen Sie eine CREATE DATABASE … AS REPLICA OF-Anweisung in jedem Zielkonto aus, um ein Replikat der angegebenen Primärdatenbank zu erstellen.
Wichtig
Als bewährte Methode empfehlen wir, jeder Sekundärdatenbank denselben Namen wie ihrer Primärdatenbank zu geben. Diese Vorgehensweise unterstützt das Verweisen auf vollqualifizierte Objekte (d. h. '<Datenbank>.<Schema>.<Objekt>'
) durch andere Objekte in derselben Datenbank, z. B. das Abfragen eines vollständig qualifizierten Tabellennamens in einer Ansicht.
Wenn eine sekundäre Datenbank einen anderen Namen als die primäre Datenbank hat, werden diese Objektreferenzen in der sekundären Datenbank unterbrochen.
Verwenden Sie die Funktion SHOW REPLICATION DATABASES, um die Liste der Primär- und Sekundärdatenbanken Ihrer Organisation abzufragen. Nachdem eine Sekundärdatenbank erstellt wurde, kann ein Kontoadministrator die Eigentümerschaft der Datenbank auf eine andere Rolle übertragen (mithilfe von GRANT OWNERSHIP).
Beispiel¶
Im folgenden Beispiel wird ein Replikat der Primärdatenbank myorg.account1.mydb1
im Konto myorg.account2
erstellt:
-- Log into the ACCOUNT2 account.
-- Query the set of primary and secondary databases in your organization.
-- In this example, the MYORG.ACCOUNT1 primary database is available to replicate.
SHOW REPLICATION DATABASES;
+------------------+-------------------------------+-----------------+----------+---------+------------+----------------------------+---------------------------------+------------------------------+-------------------+-----------------+
| snowflake_region | created_on | account_name | name | comment | is_primary | primary | replication_allowed_to_accounts | failover_allowed_to_accounts | organization_name | account_locator |
|------------------+-------------------------------+-----------------+----------+---------+------------+----------------------------+---------------------------------+------------------------------+-------------------+-----------------|
| AWS_US_WEST_2 | 2019-11-15 00:51:45.473 -0700 | ACCOUNT1 | MYDB1 | NULL | true | MYORG.ACCOUNT1.MYDB1 | MYORG.ACCOUNT2, MYORG,ACCOUNT1 | MYORG.ACCOUNT1 | MYORG | MYACCOUNT1 |
+------------------+-------------------------------+-----------------+----------+---------+------------+----------------------------+---------------------------------+------------------------------+-------------------+-----------------+
-- Create a replica of the 'mydb1' primary database
-- If the primary database has the DATA_RETENTION_TIME_IN_DAYS parameter set to a value other than the default value,
-- set the same value for the parameter on the secondary database.
CREATE DATABASE mydb1
AS REPLICA OF myorg.account1.mydb1
DATA_RETENTION_TIME_IN_DAYS = 10;
-- Verify the secondary database
SHOW REPLICATION DATABASES;
+------------------+-------------------------------+---------------+----------+---------+------------+-------------------------+---------------------------------+------------------------------+-------------------+-----------------+
| snowflake_region | created_on | account_name | name | comment | is_primary | primary | replication_allowed_to_accounts | failover_allowed_to_accounts | organization_name | account_locator |
|------------------+-------------------------------+---------------+----------+---------+------------+------------------------------------------+----------------+------------------------------+-------------------------------------|
| AWS_US_WEST_2 | 2019-11-15 00:51:45.473 -0700 | ACCOUNT1 | MYDB1 | NULL | true | MYORG.ACCOUNT1.MYDB1 | MYORG.ACCOUNT2, MYORG.ACCOUNT1 | MYORG.ACCOUNT1 | MYORG | MYACCOUNT1 |
| AWS_US_EAST_1 | 2019-08-15 15:51:49.094 -0700 | ACCOUNT2 | MYDB1 | NULL | false | MYORG.ACCOUNT1.MYDB1 | | | MYORG | MYACCOUNT2 |
+------------------+-------------------------------+---------------+----------+---------+------------+-------------------------+---------------------------------+------------------------------+-------------------+-----------------+
Schritt 5: Aktualisieren jeder Sekundärdatenbank¶
In den Anweisungen in diesem Abschnitt wird erläutert, wie eine Sekundärdatenbank aus einem Snapshot ihrer Primärdatenbank aktualisiert wird (mithilfe von ALTER DATABASE … REFRESH). Ein Snapshot enthält Änderungen an den Objekten und Daten. Für die erste Replikation einer sehr großen Primärdatenbank empfehlen wir das Erhöhen des Anweisungstimeouts.
Bemerkung
Um eine sekundäre Datenbank zu aktualisieren, muss die Rolle, mit der die Operation ausgeführt wird, über die Berechtigung OWNERSHIP für die Datenbank verfügen oder der Rolle muss eine Rolle zugewiesen werden, die die Berechtigung OWNERSHIP für die Datenbank hat.
Die Rolle, die die Aktualisierungsoperation ausführt, ist Eigentümer aller neuen Objekte, die als Ergebnis einer Datenbankaktualisierung hinzugefügt wurden.
Verwenden Sie nach der Anmeldung bei einem Konto die Funktion CURRENT_REGION, um die aktuelle Region abzufragen.
ALTER DATABASE mydb1 REFRESH;
Sie können auch eine Sekundärdatenbank über die Weboberfläche aktualisieren.
Schritt 6: Aktualisieren einer Sekundärdatenbank nach einem Zeitplan¶
Als bewährte Methode empfehlen wir, für die Aktualisierung Ihrer Sekundärdatenbank einen Zeitplan einzurichten. Dieser Abschnitt enthält eine Anleitung zum automatischen Starten einer Datenbankaktualisierung nach einem festgelegten Zeitplan.
Die Häufigkeit, mit der Sie eine Sekundärdatenbank aktualisieren, hängt vom Wiederanlaufzeitpunkt nach einem Ausfall (Recovery Point Objective, RPO) für die Daten in der Sekundärdatenbank ab. Wenn beispielsweise Anwendungen, die auf den Daten basieren, Datenverluste von bis zu 1 Stunden tolerieren können, müssen Sie die Daten mindestens stündlich aktualisieren. Wenn die Datenverlusttoleranz 5 Minuten beträgt, aktualisieren Sie die Sekundärdatenbank mindestens alle 5 Minuten.
Bemerkung
Es wird empfohlen, die erstmalige Replikation einer Primärdatenbank manuell auszuführen (mit ALTER DATABASE … REFRESH) und nur nachfolgende Aktualisierungen zu planen.
Derzeit gibt es eine Beschränkung von 60 Minuten für die einzelne Ausführung einer Aufgabe. Diese Beschränkung wurde als Schutz gegen nicht abschließende Aufgaben implementiert. In seltenen Fällen kann die Aktualisierung einer sehr großen Datenbank das Standardlimit für die Aufgabenausführung überschreiten. Um festzustellen, ob dies aufgetreten ist, fragen Sie die Tabellenfunktion TASK_HISTORY ab. Alternativ können Sie den Timeoutwert für die Aufgabe erhöhen, indem Sie ALTER TASK … SET USER_TASK_TIMEOUT_MS = <Zahl> ausführen.
Führen Sie die Schritte in diesem Abschnitt aus, um eine Datenbankaktualisierung nach einem festgelegten Zeitplan automatisch zu starten.
- Voraussetzungen:
Die folgenden Snowflake-Objekte sind in dem Konto erforderlich, in dem die Sekundärdatenbank gespeichert ist:
Die Sekundärdatenbank.
Eine separate Datenbank zum Speichern der in diesem Abschnitt erstellten neuen Objekte. Da Sekundärdatenbanken schreibgeschützt sind, muss diese Datenbank von der Sekundärdatenbank getrennt sein. Diese Datenbank muss auch die folgenden Objekte enthalten:
Schema. Verwenden Sie das Schema PUBLIC, oder erstellen Sie mit CREATE SCHEMA ein neues Schema.
Warehouse. Hier kann ein beliebiges Warehouse bereitgestellt werden, um die Syntaxanforderung zu erfüllen, das aber nicht für die Datenbankaktualisierung verwendet wird. Erstellen Sie ein neues Warehouse mit CREATE WAREHOUSE.
Aufgabe, die die Sekundärdatenbank nach einem Zeitplan aktualisiert.
- Erforderliche Berechtigungen:
Für die Schritte in diesem Abschnitt ist eine Rolle erforderlich, die in dem Konto, in dem die Sekundärdatenbank aktualisiert wird, die folgenden Berechtigungen aufweist:
Objekttyp
Objekt
Berechtigung
Anmerkungen
Konto
Konto, in dem die Sekundärdatenbank gespeichert ist
EXECUTE TASK
Erforderlich, um die neue Aufgabe auszuführen.
Datenbank
Sekundärdatenbank
OWNERSHIP
Erforderlich, um die Sekundärdatenbank zu aktualisieren.
Datenbank
Datenbank, in der die neue Aufgabe gespeichert wird.
USAGE
Schema
Schema, in dem die neue Aufgabe gespeichert wird.
USAGE, CREATE TASK
Aufgabe
OWNERSHIP
Die Rolle, die die Aufgabe erstellt, besitzt standardmäßig das Objekt. Die Eigentümerschaft kann mit GRANT
privileges
… TO ROLE auf eine andere Rolle übertragen werden.Warehouse
Warehouse, das zur Konfiguration der Aufgabe verwendet wird
USAGE
Die Angabe eines Warehouses ist für die Konfiguration der Aufgabe erforderlich, auch wenn das Warehouse nicht für die Ausführung der Aufgabe oder für die Aktualisierungsoperation verwendet wird.
- Schritte:
Führen Sie die folgenden Schritte für jede Sekundärdatenbank aus, die Sie nach einem Zeitplan aktualisieren möchten:
Erstellen Sie eine Aufgabe, mit der die Datenbankaktualisierung nach einem Zeitplan gestartet wird (mithilfe von CREATE TASK). Beachten Sie, dass obwohl die CREATE TASK-Syntax zur Angabe eines Replikationsplans ein Warehouse erfordert, das Warehouse nicht für die Replikation verwendet wird.
Erstellen Sie beispielsweise eine Aufgabe mit dem Namen
refresh_mydb1_task
, die alle 10 Minuten und einem Timeout von 4 Stunden eine Sekundärdatenbank mit dem Namenmydb1
aktualisiert. Die Aufgabe wird mit dem vorhandenen Warehousemywh
konfiguriert:CREATE TASK refresh_mydb1_task WAREHOUSE = mywh SCHEDULE = '10 minute' USER_TASK_TIMEOUT_MS = 14400000 AS ALTER DATABASE mydb1 REFRESH;
Eine Aufgabe wird bei ihrer Erstellung standardmäßig angehalten. Setzen Sie die Aufgabe fort, um sie auf Grundlage der in der Aufgabendefinition angegebenen Parameter auszuführen:
ALTER TASK refresh_mydb1_task RESUME;
Beispiel¶
Führen Sie die folgenden SQL-Anweisungen in Ihrem bevorzugten Snowflake-Client aus, um Replikation und Failover zu aktivieren, eine erste Datenbankaktualisierung durchzuführen und geplante Aktualisierungen einzurichten.
Von Quellkonto ausführen¶
-- The commands below are executed from the source account
-- View replication enabled accounts
SHOW REPLICATION ACCOUNTS;
ALTER DATABASE mydb ENABLE REPLICATION TO ACCOUNTS myorg.account2, myorg.account3;
ALTER DATABASE mydb ENABLE FAILOVER TO ACCOUNTS myorg.account2, myorg.account3;
Von jedem Zielkonto ausführen¶
-- The commands below are executed from each target account
-- View replication enabled databases
-- Note the primary column of the source database for the CREATE DATABASE statement below
SHOW REPLICATION DATABASES;
-- If the primary database has the DATA_RETENTION_TIME_IN_DAYS parameter set to a value other than the default value,
-- set the same value for the parameter on the secondary database.
CREATE DATABASE mydb
AS REPLICA OF myorg.account1.mydb
DATA_RETENTION_TIME_IN_DAYS = 10;
-- Increase statement timeout for initial refresh
-- Optional but recommended for initial refresh of a large database
ALTER SESSION SET STATEMENT_TIMEOUT_IN_SECONDS = 604800;
-- If you have an active warehouse in current session, update warehouse statement timeout
SELECT CURRENT_WAREHOUSE();
ALTER WAREHOUSE my_wh SET STATEMENT_TIMEOUT_IN_SECONDS = 604800;
-- Reset warehouse statement timeout after initial refresh
ALTER WAREHOUSE my_wh UNSET STATEMENT_TIMEOUT_IN_SECONDS;
-- Refresh a secondary database
ALTER DATABASE mydb REFRESH;
-- Create task
-- Set up refresh schedule for each secondary database using a separate database
USE DATABASE my_db2;
-- Create a task and RESUME the task for each secondary database
-- Edit the task schedule and timeout for your specific use case
CREATE TASK my_refresh_task
WAREHOUSE = my_wh
SCHEDULE = '10 minute'
USER_TASK_TIMEOUT_MS = 14400000
AS
ALTER DATABASE mydb REFRESH;
-- Start task
ALTER TASK my_refresh_task RESUME;
Verwenden des veralteten Konto-Locators¶
Obwohl das alte Format snowflake_region.account_locator
derzeit bei der Identifizierung eines Kontos in Replikations- und Failover-Befehlen unterstützt wird, wird von seiner Verwendung abgeraten, da es in Zukunft nicht mehr funktionieren könnte.
Erhöhen des Anweisungstimeouts für die erstmalige Replikation¶
Bei der Datenbankreplikation werden zum Kopieren von Objekten und Daten anstelle eines eigenen virtuellen Warehouse die von Snowflake bereitgestellten Computeressourcen verwendet. Der Sitzungs-/Objektparameter STATEMENT_TIMEOUT_IN_SECONDS steuert jedoch weiterhin, wie lange eine Anweisung ausgeführt wird, bevor sie abgebrochen wird. Der Standardwert ist 172800
(2 Tage). Da die erstmalige Replikation einer sehr großen Primärdatenbank länger als 2 Tage dauern kann (abhängig von der Menge der Metadaten in der Datenbank sowie der Menge der Daten in den Datenbankobjekten), empfehlen wir, den Wert STATEMENT_TIMEOUT_IN_SECONDS für die Sitzung, in der Sie den Replikationsoperation ausführen, auf 604800
(7 Tage, Maximalwert) zu erhöhen.
Führen Sie die folgende ALTER SESSION-Anweisung aus, bevor Sie in derselben Sitzung die Anweisung ALTER DATABASE secondary_db_name REFRESH
(Name_der_Sekundärdatenbank) ausführen:
ALTER SESSION SET STATEMENT_TIMEOUT_IN_SECONDS = 604800;
Beachten Sie, dass der Parameter STATEMENT_TIMEOUT_IN_SECONDS auch für das aktive Warehouse einer Sitzung gilt. Der Parameter berücksichtigt den niedrigeren Wert, der auf Sitzungs- oder Warehouse-Ebene festgelegt wurde. Wenn Sie in der aktuellen Sitzung ein aktives Warehouse haben, setzen Sie STATEMENT_TIMEOUT_IN_SECONDS auch für dieses Warehouse auf 604800
(mithilfe von ALTER WAREHOUSE).
Beispiel:
-- determine the active warehouse in the current session (if any)
SELECT CURRENT_WAREHOUSE();
+---------------------+
| CURRENT_WAREHOUSE() |
|---------------------|
| MY_WH |
+---------------------+
-- change the STATEMENT_TIMEOUT_IN_SECONDS value for the active warehouse
ALTER WAREHOUSE my_wh SET STATEMENT_TIMEOUT_IN_SECONDS = 604800;
Sie können den Parameterwert nach Abschluss der Replikationsoperation auf den Standardwert zurücksetzen:
ALTER WAREHOUSE my_wh UNSET STATEMENT_TIMEOUT_IN_SECONDS;
Überwachen des Fortschritts einer Datenbankaktualisierung¶
Um den aktuellen Status der erstmaligen Datenbankreplikation oder einer anschließenden Aktualisierung der Sekundärdatenbank zu ermitteln, rufen Sie die Tabellenfunktion DATABASE_REFRESH_PROGRESS , DATABASE_REFRESH_PROGRESS_BY_JOB (im Snowflake Information Schema) ab.
Eine Datenbankaktualisierungsoperation kann je nach zu replizierender Datenmenge mehrere Stunden oder länger dauern.
Rufen Sie eine der beiden folgenden Funktionen ab, um den Replikationsverlauf für eine angegebene Datenbank innerhalb eines angegebenen Datumsbereichs anzuzeigen:
Tabellenfunktion DATABASE_REPLICATION_USAGE_HISTORY (in Snowflake Information Schema). Diese Funktion gibt die Warehouse-Nutzung der letzten 14 Tage zurück.
Ansicht DATABASE_REPLICATION_USAGE_HISTORY (in Account Usage). Diese Ansicht gibt die Replikationsnutzungsaktivität der letzten 365 Tage (1 Jahr) zurück.
Beispiel¶
Überwachen Sie den Fortschritt der Aktualisierung der Sekundärdatenbank mydb1
:
select *
from table(information_schema.database_refresh_progress(mydb1));
Überwachen des Fortschritts einer Datenbankaktualisierung über die klassische Konsole¶
Starten Sie manuell über die klassische Weboberfläche die Aktualisierung der Sekundärdatenbank, um einen dynamischen Fortschrittsbalken anzuzeigen, der den aktuellen Status der Aktualisierungsoperation mit Statistiken anzeigt.
So starten Sie die Aktualisierungsoperation für eine Sekundärdatenbank:
Wählen Sie auf der klassischen Weboberfläche die Registerkarte Databases » Replication aus.
Wählen Sie die zu aktualisierende Sekundärdatenbank aus.
Wählen Sie die Schaltfläche Refresh now aus. Das Dialogfenster Refresh Database wird geöffnet.
Wählen Sie die Schaltfläche Refresh aus.
In der Spalte Last Refresh Status wird der Status der aktuellen Aktualisierungsoperation angezeigt. Der Fortschrittsbalken wird dynamisch aktualisiert.
Die Refresh History-Statistik im Seitenfenster zeigt auch den aktuellen Aktualisierungsstatus zusammen mit der Aktualisierungsstartzeit, der Anzahl der übertragenen Bytes und anderen Statistiken an.
Anzeigen des Verlaufs der Datenbankaktualisierung¶
Fragen Sie die Tabellenfunktion DATABASE_REFRESH_HISTORY (im Snowflake Information Schema) ab, um den Verlauf der Aktualisierungsoperationen der Sekundärdatenbank anzuzeigen. Diese Funktion gibt die Datenbankaktualisierungsaktivitäten der letzten 14 Tage zurück.
oder
Fragen Sie die Ansicht DATABASE_REPLICATION_USAGE_HISTORY (im Schema Account Usage der freigegebenen Snowflake-Datenbank) ab. Diese Ansicht gibt die Nutzung durch die Datenbankreplikation der letzten 365 Tage (1 Jahr) zurück.
Beispiel¶
Zeigen Sie den Verlauf der Aktualisierungsoperation der Sekundärdatenbank mydb1
an:
select *
from table(information_schema.database_refresh_history(mydb1));
Überwachen der Kosten der Datenbankreplikation¶
Bei der Replikation einzelner Datenbanken mit der Datenbankreplikation können Benutzer mit der Rolle ACCOUNTADMIN Snowsight, die klassische Weboberfläche oder SQL verwenden, um für Ihr Snowflake-Konto die innerhalb eines bestimmten Datumsbereichs übertragene Replikationsdatenmenge (in Byte) anzuzeigen.
So zeigen Sie die Menge der übertragenen Daten für Ihr Konto an:
- Snowsight:
Select Admin » Cost Management
- Classic Console:
Klicken Sie auf Account » Billing & Usage.
Die Nutzung der Replikation wird mittels eines speziellen, von Snowflake bereitgestellten Warehouse namens REPLICATION angezeigt. Klicken Sie auf die Schaltfläche Data Transfer, um die Datenübertragungskosten anzuzeigen. Beachten Sie, dass die Weboberfläche die Datenübertragungskosten für die Replikation nicht weiter aufschlüsselt.
- SQL:
Führen Sie eine Abfrage auf einer der folgenden Optionen durch:
Tabellenfunktion DATABASE_REPLICATION_USAGE_HISTORY (in Snowflake Information Schema). Diese Funktion gibt die Nutzung durch die Datenbankreplikation der letzten 14 Tage zurück.
Ansicht Ansicht DATABASE_REPLICATION_USAGE_HISTORY (in Account Usage). Diese Ansicht gibt die Nutzung durch die Datenbankreplikation der letzten 365 Tage (1 Jahr) zurück.
Die folgenden Abfragen können auf der Ansicht DATABASE_REPLICATION_USAGE_HISTORY ausgeführt werden:
Abfrage: Kostenverlauf für Replikation (nach Tag, nach Objekt)
Diese Abfrage liefert eine umfassende Liste der replizierten Datenbanken und das Volumen der über den Replikationsdienst in den letzten 30 Tagen verbrauchten Credits, aufgeschlüsselt nach Tagen. Unregelmäßigkeiten beim Credit-Verbrauch oder ein gleichbleibend hoher Verbrauch sind Anzeichen, dass weitere Untersuchungen erforderlich sind.
SELECT TO_DATE(start_time) AS date, database_name, SUM(credits_used) AS credits_used FROM snowflake.account_usage.database_replication_usage_history WHERE start_time >= DATEADD(month,-1,CURRENT_TIMESTAMP()) GROUP BY 1,2 ORDER BY 3 DESC;Abfrage: Replikationsverlauf und Tagesdurchschnitt über m Tage
Diese Abfrage gibt den durchschnittlichen täglichen Credit-Verbrauch durch die Replikation für das letzte Jahr, gruppiert nach Woche zurück. Auf diese Weise lassen sich etwaige Anomalien in Tagesdurchschnittswerten feststellen, die für die Untersuchung von Verbrauchsspitzen oder -veränderungen dienen können.
WITH credits_by_day AS ( SELECT TO_DATE(start_time) AS date, SUM(credits_used) AS credits_used FROM snowflake.account_usage.database_replication_usage_history WHERE start_time >= DATEADD(year,-1,CURRENT_TIMESTAMP()) GROUP BY 1 ORDER BY 2 DESC ) SELECT DATE_TRUNC('week',date), AVG(credits_used) AS avg_daily_credits FROM credits_by_day GROUP BY 1 ORDER BY 1;
Vergleichen von Datensets in Primär- und Sekundärdatenbanken¶
Verwenden Sie optional die Funktion HASH_AGG, um die Zeilen in einer zufälligen Menge von Tabellen einer Primär- und einer Sekundärdatenbank zu vergleichen und 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ärdatenbank und der Primärdatenbank ab (ab dem Zeitstempel des Snapshots der Primärdatenbank), und vergleichen Sie die Ausgabe.
Beispiel¶
Ausgeführt auf der Sekundärdatenbank¶
Fragen Sie in der Sekundärdatenbank die Tabellenfunktion DATABASE_REFRESH_PROGRESS ab (im Snowflake Information Schema). Beachten Sie den Wert
snapshot_transaction_timestamp
in der SpalteDETAILS
für die PhasePRIMARY_UPLOADING_DATA
. Dies ist der Zeitstempel für den neuesten Snapshot der Primärdatenbank.select parse_json(details)['snapshot_transaction_timestamp'] from table(information_schema.database_refresh_progress(mydb)) where phase_name = 'PRIMARY_UPLOADING_DATA';
Fragen Sie die Funktion HASH_AGG für eine angegebene Tabelle ab. Die folgende Abfrage gibt einen Hash-Wert für alle Zeilen der Tabelle
mytable
zurück:SELECT HASH_AGG( * ) FROM mytable;
Ausgeführt auf der Primärdatenbank¶
Fragen Sie in der Primärdatenbank auf derselben Tabelle die Funktion HASH_AGG ab. Geben Sie mithilfe von Time Travel den Zeitstempel an, zu dem der letzte Snapshot der Sekundärdatenbank erstellt wurde:
SELECT HASH_AGG( * ) FROM mytable AT(TIMESTAMP => '<snapshot_transaction_timestamp>'::TIMESTAMP);
Vergleichen Sie die Ergebnisse der beiden Abfragen. Die Ausgabe sollte identisch sein.
Löschen einer Sekundärdatenbank¶
Sie können eine sekundäre Datenbank jederzeit mit dem Befehl DROP DATABASE löschen. Nur der Datenbankeigentümer (d. h. die Rolle mit der Berechtigung OWNERSHIP für die Datenbank) kann die Datenbank löschen.
Löschen einer Primärdatenbank¶
Eine primäre Datenbank kann nicht gelöscht werden, wenn eine oder mehrere Replikate dieser Datenbank (d. h. sekundäre Datenbanken) vorhanden sind. Um die Primärdatenbank zu löschen, müssen Sie zuerst eine Sekundärdatenbank zur Primärdatenbank heraufstufen, erst danach können Sie die bisherige Primärdatenbank löschen. Löschen Sie alternativ alle sekundären Datenbanken der primären Datenbank, und löschen Sie dann die primäre Datenbank.
Beachten Sie, dass nur der Datenbankeigentümer die Datenbank löschen kann.