Replizieren von Datenbanken über mehrere Konten

Unter diesem Thema werden die Schritte beschrieben, die zum Replizieren von Datenbanken über mehrere Snowflake-Konten in verschiedenen Regionen hinweg und zum Synchronisieren der Datenbankobjekte und gespeicherten Daten erforderlich sind.

Unter diesem Thema:

Support der Region für Datenbankreplikation und Failover/Failback

Alle Snowflake-Regionen in Amazon Web Services, Google Cloud Platform und Microsoft Azure unterstützen Datenbankreplikation und Failover/Failback (mit Ausnahme von US Gov Virginia in Microsoft Azure).

Beachten Sie, dass Konten Datenbanken zwischen Virtual Private Snowflake (VPS) und Regionen mit mehreren Mandanten replizieren können, wodurch das Data Sharing und die Migration von Konten vereinfacht werden. Diese Fähigkeit ist standardmäßig deaktiviert. VPS-Konten müssen sich an den Snowflake-Support wenden, um den Zugriff zu ermöglichen.

Weboberfläche für Datenbankreplikation und Failover/Failback

Kontoadministratoren (Benutzer mit der Rolle ACCOUNTADMIN) können auf der Snowflake-Weboberfläche im Bereich Replication der Registerkarte Databases Databases tab die meisten Aktionen zum Konfigurieren und Verwalten der Datenbankreplikation auszuführen, einschließlich der folgenden Aktionen:

  • Heraufstufen einer lokalen Datenbank zur primären Datenbank

  • Aktivieren des Failover für eine primäre Datenbank (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ären Datenbanken als primäre Datenbank (Business Critical Edition-Konten oder höher)

  • Deaktivieren der Replikation und/oder des 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 und die erstmalige Replikation dieser Primärdatenbank auf ein anderes Konto durchführen.

Wichtig

Für Zielkonten ist standardmäßig weder Tri-Secret Secure noch AWS PrivateLink konfiguriert. Wenn Tri-Secret Secure oder PrivateLink für Compliance-, Sicherheits- oder andere Zwecke erforderlich ist, müssen Sie sicherstellen, dass diese Funktionen im Zielkonto konfiguriert sind.

Schritt 2: Anzeigen aller Konten Ihrer Organisation

Rufen Sie die Liste der Konten in Ihrer Organisation ab. Jede in diesen Konten vorhandene permanente oder temporäre Datenbank kann so geändert werden, dass sie als primäre Datenbank dient. Replikate einer Primärdatenbank (d. h. Sekundärdatenbanken) können nur in diesen Konten erstellt werden.

Bemerkung

Die SQL-Anweisung in diesem Abschnitt kann nur von Kontoadministratoren (Benutzer mit der Rolle ACCOUNTADMIN) ausgeführt werden.

Wie Sie die Liste der Konten in Ihrer Organisation anzeigen können, ist unter SHOW REPLICATION ACCOUNTS beschrieben.

SHOW REPLICATION ACCOUNTS;

+------------------+---------------------------------+---------------+------------+
| snowflake_region | created_on                      | name          | comment    |
|------------------+---------------------------------+---------------+------------|
| AWS_US_WEST_2    | 2018-11-19 16:11:12.720 -0700   | MYACCOUNT1    |            |
| AWS_US_EAST_1    | 2019-06-02 14:12:23.192 -0700   | MYACCOUNT2    |            |
+------------------+---------------------------------+---------------+------------+

In der folgenden Tabelle wird die vollständige Liste der Snowflake-Regions-IDs angezeigt:

Snowflake-Regions-IDs

Region

Regions-ID

Snowflake-Regions-ID

Anmerkungen

Amazon Web Services (AWS)

US West (Oregon)

us-west-2

aws_us_west_2

US East (Ohio)

us-east-2.aws

aws_us_east_2

US East (N. Virginia)

us-east-1

aws_us_east_1

US East (Commercial Gov - N. Virginia)

us-east-1-gov.aws

aws_us_east_1_gov

Nur für Business Critical-Konten (oder höher) verfügbar. Befindet sich nicht in AWS GovCloud (US), einer separaten, dedizierten Cloud, die von Snowflake noch nicht unterstützt wird.

Canada (Central)

ca-central-1.aws

aws_ca_central_1

EU (Irland)

eu-west-1

aws_eu_west_1

EU (Frankfurt)

eu-central-1

aws_eu_central_1

Asia Pacific (Tokio)

ap-northeast-1.aws

aws_ap_northeast_1

Asia Pacific (Mumbai)

ap-south-1.aws

aws_ap_south_1

Asia Pacific (Singapur)

ap-southeast-1

aws_ap_southeast_1

Asia Pacific (Sydney)

ap-southeast-2

aws_ap_southeast_2

Google Cloud Platform (GCP)

US Central1 (Iowa)

us-central1.gcp

gcp_us_central1

Europe West2 (London)

europe-west2.gcp

gcp_europe_west2

Europe West4 (Niederlande)

europe-west4.gcp

gcp_europe_west4

Microsoft Azure

West US 2 (Washington)

west-us-2.azure

azure_westus2

East US 2 (Virginia)

east-us-2.azure

azure_eastus2

US Gov Virginia

us-gov-virginia.azure

azure_usgovvirginia

Nur für Business Critical-Konten (oder höher) verfügbar.

Canada Central (Toronto)

canada-central.azure

azure_canadacentral

West Europe (Niederlande)

west-europe.azure

azure_westeurope

Southeast Asia (Singapur)

southeast-asia.azure

azure_southeastasia

Switzerland North (Zürich)

switzerland-north.azure

azure_switzerlandnorth

Australia East (New South Wales)

australia-east.azure

azure_australiaeast

Schritt 3: 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.

Bemerkung

Die SQL-Anweisung in diesem Abschnitt kann nur von Kontoadministratoren (Benutzer mit der Rolle ACCOUNTADMIN) ausgeführt werden.

Beispiel

Heraufstufen der lokalen Datenbank mydb1 (in Region aws_us_west_2) als primäre Datenbank und Festlegen der Konten myaccount2 und myaccount3 (in Regionen aws_us_east_1 (AWS) bzw. azure_westeurope (Azure)) für das Speichern eines Replikats dieser Datenbank:

ALTER DATABASE mydb1 ENABLE REPLICATION TO ACCOUNTS aws_us_east_1.myaccount2, azure_westeurope.myaccount3;

Schritt 4: Aktivieren des Failovers für eine primäre Datenbank

Bemerkung

Führen Sie diesen Schritt nur aus, wenn Sie vorhaben, diese Primärdatenbank für ein Failover auf ein anderes Konto zu konfigurieren. Weitere Informationen dazu finden Sie unter Einführung in Geschäftskontinuität und Notfallwiederherstellung.

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 für die primäre Datenbank mydb1 (in Region aws_us_west_2) auf die Konten myaccount2 und myaccount3 (in Regionen aws_us_east_1 (AWS) bzw. azure_westeurope (Azure)). In diesem Beispiel wird angenommen, dass die Primärdatenbank im Konto myaccount1 gespeichert ist. Der Befehl ALTER DATABASE muss in diesem Konto ausgeführt werden:

ALTER DATABASE mydb1 ENABLE FAILOVER TO ACCOUNTS aws_us_east_1.myaccount2, azure_westeurope.myaccount3;

Schritt 5: Erstellen einer sekundären Datenbank

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 3: 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.

Wichtig

Als bewährte Methode empfehlen wir, jeder sekundären Datenbank denselben Namen wie ihrer primären Datenbank zu geben. Diese Vorgehensweise unterstützt das Verweisen auf vollständig qualifizierte 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ären und sekundären Datenbanken Ihrer Organisation abzufragen.

Bemerkung

Die SQL-Anweisung in diesem Abschnitt kann nur von Kontoadministratoren (Benutzer mit der Rolle ACCOUNTADMIN) ausgeführt werden.

Nachdem eine sekundäre Datenbank 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 aws_us_west_2.myaccount1.mydb1 im Konto aws_us_east_1.myaccount2 erstellt und die automatische Aktualisierung der materialisierten Ansichten im Replikat aktiviert. Die SQL-Anweisung wird in derselben AWS-Regionsgruppe (public) ausgeführt, jedoch in einer anderen Region als das Konto, in dem die primäre Datenbank gespeichert ist:

-- Log into the AWS_US_EAST_1.MYACCOUNT2 account.

-- Query the set of primary and secondary databases in your organization.
-- In this example, the AWS_US_WEST_2.MYACCOUNT1 primary database is available to replicate.
SHOW REPLICATION DATABASES;

+------------------+-------------------------------+-----------------+----------+---------+------------+------------------------------------------+------------------+------------------------------------------------------------------+---------------------------------+
| snowflake_region | created_on                    | account_name    | name     | comment | is_primary | primary                                  | snowflake_region | replication_allowed_to_accounts                                  | failover_allowed_to_accounts    |
|------------------+-------------------------------+-----------------+----------+---------+------------+------------------------------------------+------------------+------------------------------------------------------------------+---------------------------------|
| AWS_US_WEST_2    | 2019-11-15 00:51:45.473 -0700 | MYACCOUNT1      | MYDB1    | NULL    | true       | PUBLIC.AWS_US_WEST_2.MYACCOUNT1.MYDB1    | AWS_US_WEST_2    | PUBLIC.AWS_US_EAST_1.MYACCOUNT2, PUBLIC.AWS_US_WEST_2.MYACCOUNT1 | PUBLIC.AWS_US_WEST_2.MYACCOUNT1 |
+------------------+-------------------------------+-----------------+----------+---------+------------+------------------------------------------+------------------+------------------------------------------------------------------+---------------------------------+

-- Create a replica of the 'mydb1' primary database
CREATE DATABASE mydb1
  AS REPLICA OF aws_us_west_2.myaccount1.mydb1
  AUTO_REFRESH_MATERIALIZED_VIEWS_ON_SECONDARY = TRUE;

-- Verify the secondary database
SHOW REPLICATION DATABASES;

+------------------+-------------------------------+-----------------+----------+---------+------------+------------------------------------------+------------------+------------------------------------------------------------------+---------------------------------+
| snowflake_region | created_on                    | account_name    | name     | comment | is_primary | primary                                  | snowflake_region | replication_allowed_to_accounts                                  | failover_allowed_to_accounts    |
|------------------+-------------------------------+-----------------+----------+---------+------------+------------------------------------------+------------------+------------------------------------------------------------------+---------------------------------|
| AWS_US_WEST_2    | 2019-11-15 00:51:45.473 -0700 | MYACCOUNT1      | MYDB1    | NULL    | true       | PUBLIC.AWS_US_WEST_2.MYACCOUNT1.MYDB1    | AWS_US_WEST_2    | PUBLIC.AWS_US_EAST_1.MYACCOUNT2, PUBLIC.AWS_US_WEST_2.MYACCOUNT1 | PUBLIC.AWS_US_WEST_2.MYACCOUNT1 |
| AWS_US_EAST_1    | 2019-08-15 15:51:49.094 -0700 | MYACCOUNT2      | MYDB1    | NULL    | false      | PUBLIC.AWS_US_WEST_2.MYACCOUNT1.MYDB1    | AWS_US_EAST_1    |                                                                  |                                 |
+------------------+-------------------------------+-----------------+----------+---------+------------+------------------------------------------+------------------+------------------------------------------------------------------+---------------------------------+

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.

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.

Bemerkung

Um eine sekundäre Datenbank zu aktualisieren, muss die zum Ausführen der Operation verwendete Rolle über die Berechtigung OWNERSHIP für die Datenbank verfügen.

Verwenden Sie nach der Anmeldung bei einem Konto die Funktion CURRENT_REGION, um die aktuelle Region zu überprüfen.

ALTER DATABASE mydb1 REFRESH​;

Aktualisieren einer sekundären Datenbank über die Weboberfläche

Die Snowflake-Weboberfläche bietet eine visuelle Darstellung des momentanen Aktualisierungsstatus einer sekundären Datenbank. Anweisungen finden Sie unter Überwachen des Fortschritts einer Datenbankaktualisierung über die Weboberfläche (unter diesem Thema).

Erhöhen des Anweisungstimeouts für die erstmalige Replikation

Bei der Datenbankreplikation werden zum Kopieren von Objekten und Daten die von Snowflake bereitgestellten Computeressourcen anstelle Ihres eigenen virtuellen Warehouse 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 Name_der_Sekundärdatenbank REFRESH 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;

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.

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 eine Aktualisierung einer sehr großen Datenbank das Standardlimit für die Ausführung von Aufgaben überschreiten. Um festzustellen, ob dies aufgetreten ist, fragen Sie die Tabellenfunktion TASK_HISTORY ab. Wenn die Aufgabe das geplante Zeitfenster überschritten hat, ist die Ursache häufig ein Warehouse mit zu geringer Größe. Überprüfen Sie die Warehousegröße, und erhöhen Sie diese, damit das Zeitplanfenster oder das Ein-Stunden-Limit eingehalten wird.

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

  • Die sekundäre Datenbank.

  • Eine separate Datenbank zum Speichern der in diesem Abschnitt erstellten neuen Objekte. Da sekundäre Datenbanken schreibgeschützt sind, muss diese Datenbank von der sekundären Datenbank 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 zur Bereitstellung von Computeressourcen für die Datenbankaktualisierung. 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 Berechtigungen … TO ROLE auf eine andere Rolle übertragen werden.

Warehouse

Warehouse, in dem die Aufgabe ausgeführt wurde

USAGE

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

    Syntax
    CREATE [ OR REPLACE ] TASK [ IF NOT EXISTS ] <name>
      WAREHOUSE = <string>
      SCHEDULE = { <number> MINUTE | USING CRON <expr> <time_zone> } | AFTER <string>
    AS
      ALTER DATABASE <secondary_db_name> REFRESH;
    

    Erstellen Sie beispielsweise eine Aufgabe mit dem Namen refresh_mydb1_task, die alle 10 Minuten eine sekundäre Datenbank mit dem Namen mydb1 aktualisiert. Die Aufgabe wird mit dem vorhandenen Warehouse mywh ausgeführt:

    CREATE TASK refresh_mydb1_task
      WAREHOUSE = mywh
      SCHEDULE = '10 minute'
    AS
      ALTER DATABASE mydb1 REFRESH;
    
  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;

Überwachen des Fortschritts einer Datenbankaktualisierung

Um den aktuellen Status der erstmaligen Datenbankreplikation oder einer anschließenden Aktualisierung der sekundären Datenbank zu ermitteln, rufen Sie die Tabellenfunktion DATABASE_REFRESH_PROGRESS , DATABASE_REFRESH_PROGRESS_BY_JOB (im 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:

Beispiel

Überwachen Sie den Fortschritt der Aktualisierung der sekundären Datenbank mydb1:

select *
  from table(information_schema.database_refresh_progress(mydb1));

Überwachen des Fortschritts einer Datenbankaktualisierung über die Weboberfläche

Starten Sie manuell über die Weboberfläche die Aktualisierung der sekundären Datenbank, um einen dynamischen Fortschrittsbalken anzuzeigen, der den aktuellen Status der Aktualisierungsoperation mit Statistik anzeigt.

So starten Sie die Aktualisierungsoperation für eine sekundäre Datenbank:

  1. Klicken Sie auf der Snowflake-Weboberfläche auf die Registerkarte Databases Databases tab » Replication.

  2. Wählen Sie die zu aktualisierende sekundäre Datenbank aus.

  3. Klicken Sie auf die Schaltfläche Refresh now. Das Dialogfenster Refresh Database wird geöffnet.

  4. Klicken Sie auf die Schaltfläche Refresh.

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.

Secondary refresh operation in the Snowflake web interface

Anzeigen des Verlaufs der Datenbankaktualisierung

Fragen Sie die Tabellenfunktion DATABASE_REFRESH_HISTORY (im Information Schema) ab, um den Verlauf der Aktualisierungsoperationen der sekundären Datenbank anzuzeigen. Diese Funktion gibt die Datenbankaktualisierungsaktivitäten der letzten 14 Tage zurück.

oder

Fragen Sie die Ansicht Ansicht REPLICATION_USAGE_HISTORY (im Schema Account Usage der freigegebenen Snowflake-Datenbank) ab. Diese Ansicht gibt die Replikationsnutzungsaktivität der letzten 365 Tage (1 Jahr) zurück.

Beispiel

Zeigen Sie den Verlauf der Aktualisierungsoperation der sekundären Datenbank mydb1 an:

select *
  from table(information_schema.database_refresh_history(mydb1));

Vergleichen von Datasets in primären und sekundären Datenbanken

Verwenden Sie optional die Funktion HASH_AGG, um die Zeilen in einer zufälligen Menge von Tabellen einer primären und sekundären Datenbank 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ären Datenbank und in der primären Datenbank ab (ab dem Zeitstempel des Snapshots der primären Datenbank), und vergleichen Sie die Ausgabe.

Beispiel

  1. Fragen Sie auf der sekundären Datenbank die Tabellenfunktion DATABASE_REFRESH_HISTORY ab (im Information Schema). Beachten Sie die Spalte END_TIME der Zeile, die angibt, wann die letzte Aktualisierungsoperation abgeschlossen wurde. Dies ist der Zeitstempel für den neuesten Snapshot der Primärdatenbank.

  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;
    
  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 => <primary_snapshot_timestamp>);
    
  4. Vergleichen Sie die Ergebnisse der beiden Abfragen. Die Ausgabe sollte identisch sein.