Replizieren von Datenbanken über mehrere Konten¶

Heraufstufen einer lokalen Datenbank¶

1. Melden Sie sich bei einem Snowflake-Konto an, das eine lokale Datenbank enthält, die Sie in ein oder mehrere andere Konten replizieren möchten.

2. Klicken Sie im Dropdown-Menü oben links (neben Ihrem Anmeldenamen) auf » Switch Role » ACCOUNTADMIN.

3. Klicken Sie links auf der Seite Databases im Datenbankobjekt-Explorer auf eine lokale Datenbank. Die Datenbank-Detailseite wird geöffnet.

4. Klicken Sie in der oberen rechten Ecke der Seite » Enable Replication auf die Aktionsschaltfläche (…). Das Dialogfenster Enable replication wird geöffnet.

   In diesem Dialogfeld können Sie die folgenden Aktionen durchführen:

   • Heraufstufen einer lokalen Datenbank zur primären Datenbank

   • Erstellen einer sekundären Datenbank in einem oder mehreren Zielkonten

   • Aktualisieren jeder sekundären Datenbank einmal, nachdem sie erstellt wurde

5. Aktivieren Sie für jedes Zielkonto dieser Datenbank die Optionen zum Erstellen einer sekundären Datenbank und zum Aktualisieren der Datenbank.

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

Verwalten einer sekundären Datenbank¶

1. Melden Sie sich bei einem Konto an, das eine sekundäre Datenbank enthält.

2. Klicken Sie im Dropdown-Menü oben links (neben Ihrem Anmeldenamen) auf » Switch Role » ACCOUNTADMIN.

3. Klicken Sie links auf der Seite Databases im Datenbankobjekt-Explorer auf eine sekundäre Datenbank. Die Datenbank-Detailseite wird geöffnet.

4. Klicken Sie auf die Registerkarte Replication.

   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. Dieses Feature erfordert Business Critical (oder höher).

   • Aktualisieren Sie die sekundäre Datenbank.

   • Kopieren Sie eine Vorlage, um eine Aufgabe zu erstellen, mit der die sekundäre Datenbank 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.

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 temporäre 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äre Datenbank¶

Ä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äre Datenbank) gespeichert werden kann, sodass Benutzer in diesen Konten Objekte der sekundären Datenbank abfragen können.

ALTER DATABASE mydb1 ENABLE REPLICATION TO ACCOUNTS myorg.account2, myorg.account3;

Schritt 3: Aktivieren des Failovers für eine Primärdatenbank¶

Aktivieren Sie das Failover einer Primärdatenbank für ein oder mehrere Konten Ihrer Organisation mithilfe einer ALTER DATABASE … ENABLE FAILOVER TO ACCOUNTS-Anweisung. 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.

-- 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äre Datenbank 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äre Datenbank angegeben ist.

Führen Sie eine CREATE DATABASE … AS REPLICA OF-Anweisung in jedem Zielkonto aus, um ein Replikat der angegebenen Primärdatenbank zu erstellen.

Verwenden Sie die Funktion SHOW REPLICATION DATABASES, um die Liste der primären und sekundären Datenbanken 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).

-- 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ären Datenbank¶

In den Anweisungen in diesem Abschnitt wird erläutert, wie eine sekundäre Datenbank aus einem Snapshot ihrer primären Datenbank 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.

Beachten Sie, dass der Eigentümer der sekundären Datenbank (Rolle mit der Berechtigung OWNERSHIP für die Datenbank) alle neuen Objekte besitzt, die infolge 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äre Datenbank über die Weboberfläche aktualisieren.

Schritt 6: Aktualisieren einer sekundären Datenbank nach einem Zeitplan¶

Als bewährte Methode empfehlen wir, die Aktualisierung Ihrer sekundären Datenbank zu planen. Dieser Abschnitt enthält Anweisungen zum automatischen Starten einer Datenbankaktualisierung nach einem festgelegten Zeitplan.

Die Häufigkeit, mit der Sie eine sekundäre Datenbank aktualisieren, hängt vom Wiederanlaufzeitpunkt nach einem Ausfall (Recovery Point Objective, RPO) für die Daten in der sekundären Datenbank 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äre Datenbank mindestens alle 5 Minuten.

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äre Datenbank gespeichert ist:

• Die sekundäre Datenbank.

• 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äre Datenbank 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äre Datenbank aktualisiert wird, die folgenden Berechtigungen aufweist:

Objekttyp	Objekt	Berechtigung	Anmerkungen
Konto	Konto, in dem die sekundäre Datenbank gespeichert ist	EXECUTE TASK	Erforderlich, um die neue Aufgabe auszuführen.
Datenbank	Sekundäre Datenbank	OWNERSHIP	Erforderlich, um die sekundäre Datenbank 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äre Datenbank aus, die Sie nach einem Zeitplan aktualisieren möchten:

1. Erstellen Sie eine Aufgabe, mit der die Datenbankaktualisierung nach einem Zeitplan gestartet wird (mithilfe von CREATE TASK). Beachten Sie, dass obwohl die CREATETASK-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äre Datenbank mit dem Namen mydb1 aktualisiert. Die Aufgabe wird mit dem vorhandenen Warehouse mywh konfiguriert:

   CREATE TASK refresh_mydb1_task
     WAREHOUSE = mywh
     SCHEDULE = '10 minute'
     USER_TASK_TIMEOUT_MS = 14400000
   AS
     ALTER DATABASE mydb1 REFRESH;
   

   Copy

2. 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;

Copy

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.

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

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

Ausgeführt auf der Sekundärdatenbank¶

1. Fragen Sie auf der Sekundärdatenbank die Tabellenfunktion DATABASE_REFRESH_PROGRESS ab (im Snowflake Information Schema). Beachten Sie den snapshot_transaction_timestamp in der Spalte DETAILS für die Phase PRIMARY_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';
   

   Copy

2. Fragen Sie die Funktion HASH_AGG für eine angegebene Tabelle ab. Die folgende Abfrage gibt einen Hashwert für alle Zeilen der Tabelle mytable zurück:

   SELECT HASH_AGG( * ) FROM mytable;
   

   Copy

Ausgeführt auf der Primärdatenbank¶

3. 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ären Datenbank erstellt wurde:

   SELECT HASH_AGG( * ) FROM mytable AT(TIMESTAMP => '<snapshot_transaction_timestamp>'::TIMESTAMP);
   

   Copy

4. Vergleichen Sie die Ergebnisse der beiden Abfragen. Die Ausgabe sollte identisch sein.