Einführung in die Datenbankreplikation über mehrere Konten¶
Mithilfe dieses Features können Sie Datenbanken zwischen Snowflake-Konten (innerhalb derselben Organisation) replizieren und die Datenbankobjekte und gespeicherten Daten synchronisieren. Die Datenbankreplikation wird über verschiedene Regionen und Cloudplattformen hinweg unterstützt.
Unter diesem Thema:
Was ist eine Primärdatenbank?¶
Die Replikation kann für jede vorhandene permanente oder transiente Datenbank aktiviert werden. Durch das Aktivieren der Replikation wird die Datenbank als Primärdatenbank gekennzeichnet. In einem Konto können beliebig viele Datenbanken als Primärdatenbanken festgelegt werden. Ebenso kann eine Primärdatenbank auf eine beliebige Anzahl von Konten in Ihrer Organisation repliziert werden. Dies beinhaltet das Erstellen einer Sekundärdatenbank als Replikat einer angegebenen Primärdatenbank in jedem Zielkonto. Diese Konten befinden sich normalerweise in anderen Regionen auf derselben oder einer anderen Cloudplattform, oder sie befinden sich in derselben Region wie das Quellkonto.
Alle DML/DDL-Operationen werden auf der Primärdatenbank ausgeführt. Jede schreibgeschützte, sekundäre Datenbank kann regelmäßig mit einem Snapshot der primären Datenbank aktualisiert werden. Dabei werden alle Daten sowie DDL-Operationen für Datenbankobjekte (d. h. Schemas, Tabellen, Ansichten usw.) repliziert.
Überblick zur Datenbankreplikation¶
Eine vollständige Liste der replizierten Datenbankobjekte finden Sie unter Replizierte Datenbankobjekte.
Andere Objekte in einem Konto¶
Derzeit wird die Datenbankreplikation nur für Datenbanken unterstützt. Andere Typen von Objekten in einem Konto können mit der Kontoreplikation repliziert werden. Eine vollständige Liste der unterstützten Objekte für die Kontoreplikation finden Sie unter Replizierte Objekte.
Zugriffssteuerung¶
Berechtigungen, die für Datenbankobjekte erteilt wurden, werden nicht in eine Sekundärdatenbank repliziert. Dazu gehören sowohl Berechtigungen für bestehende Datenbankobjekte als auch Berechtigungen für zukünftige Objekte (d. h. zukünftige Berechtigungszuweisungen).
Berechtigungszuweisungen können mit der Kontoreplikation repliziert werden.
Parameter¶
Kontoparameter werden bei der Datenbankreplikation nicht repliziert. Kontoparameter können bei der Kontoreplikation repliziert werden.
Objektparameter, die auf Schema- oder Schemaobjektebene festgelegt sind, werden repliziert:
Parameter
Objekte
Schema, Tabelle
Schema, Tabelle
Schema, Tabelle
Schema, Pipe
Schema, Tabelle
Die Parameterreplikation gilt nur für Objekte in der Datenbank (Schema, Tabelle) und nur, wenn der Parameter explizit mit CREATE <Objekt> <Parameter> oder ALTER <Objekt> … SET <Parameter> festgelegt wurde. Parameter auf Datenbankebene werden nicht repliziert.
Parameter, die explizit für Objekte in der Primärdatenbank festgelegt wurden, überschreiben Parameter, die für Objekte in der Sekundärdatenbank festgelegt wurden. Wenn beispielsweise die Primärdatenbank ein Schema s1 hat, bei dem DATA_RETENTION_TIME_IN_DAYS auf 10 gesetzt ist, und für die Sekundärdatenbank auf Datenbankebene DATA_RETENTION_TIME_IN_DAYS auf 1 gesetzt ist, wird DATA_RETENTION_TIME_IN_DAYS für Schema s1 in der Sekundärdatenbank nach der Replikation auf 10 gesetzt sein.
Parameter, die explizit auf Datenbankebene in Sekundärdatenbank gesetzt wurden, werden nicht überschrieben. Wenn beispielsweise der Parameter DATA_RETENTION_TIME_IN_DAYS der Sekundärdatenbank explizit auf 1 und der Parameter DATA_RETENTION_TIME_IN_DAYS der Primärdatenbank explizit auf 10 gesetzt ist, bleibt DATA_RETENTION_TIME_IN_DAYS der Sekundärdatenbank auch nach der Replikation auf 1 gesetzt.
[1] Beachten Sie, dass die PIPE-Objekte nicht repliziert werden. Wenn der Parameter PIPE_EXECUTION_PAUSED auf Schemaebene in der Primärdatenbank festgelegt ist, wird er in die Sekundärdatenbank repliziert. Wenn die Sekundärdatenbank im Falle eines Failover zur Primärdatenbank heraufgestuft und eine Pipe erstellt wird, wird die Parametereinstellung wirksam.
Datenbankreplikation auf Konten in niedrigeren Editionen¶
Wenn eine lokale Datenbank als primäre Datenbank heraufgestuft wird und eine der folgenden Bedingungen erfüllt ist, zeigt Snowflake eine Fehlermeldung an:
Die Primärdatenbank befindet sich in einem Business Critical-Konto (oder höher), aber eines oder mehrere der zur Replikation genehmigten Konten befinden sich in niedrigeren Editionen. Die Business Critical Edition ist für Snowflake-Konten mit äußerst sensiblen Daten vorgesehen.
Die Primärdatenbank befindet sich in einem Business Critical-Konto (oder höher), und es ist eine unterzeichnete Geschäftspartner-Vereinbarung vorhanden, um PHI-Daten gemäß HIPAA- und HITRUST CSF-Vorschriften in dem Konto zu speichern, jedoch gibt es für die zur Replikation genehmigte Konten keine solche Vereinbarung, unabhängig davon, ob es sich um Business Critical-Konten (oder höher) handelt.
Dieses Verhalten wird implementiert, um zu verhindern, dass Kontoadministratoren von Business Critical-Konten (oder höher) versehentlich vertrauliche Daten auf Konten mit niedrigeren Editionen replizieren.
Ein Kontoadministrator kann dieses Standardverhalten überschreiben, indem er beim Ausführen der Anweisung ALTER DATABASE … ENABLE REPLICATION TO ACCOUNTS die Klausel IGNORE EDITION CHECK einfügt. Wenn IGNORE EDITION CHECK festgelegt ist, kann die Primärdatenbank in jeder Snowflake-Edition auf die angegebenen Konten repliziert werden.
Aktuelle Einschränkungen bei Replikationen¶
Das Aktualisieren einer sekundären Datenbank wird blockiert, wenn in der primären Datenbank eine externe Tabelle vorhanden ist.
Aus Freigaben erstellte Datenbanken können nicht repliziert werden.