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.

Bemerkung

Snowflake empfiehlt die Verwendung des Features Einführung in Replikation und Failover über mehrere Konten 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:

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.

Übersicht 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

DATA_RETENTION_TIME_IN_DAYS

Schema, Tabelle

DEFAULT_DDL_COLLATION

Schema, Tabelle

MAX_DATA_EXTENSION_TIME_IN_DAYS

Schema, Tabelle

PIPE_EXECUTION_PAUSED [1]

Schema, Pipe

QUOTED_IDENTIFIERS_IGNORE_CASE

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 in Konten mit niedrigeren Editionen

Wenn eine lokale Datenbank als Primärdatenbank 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 genehmigten 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 beim Ausführen der Anweisung ALTER DATABASE … ENABLE REPLICATION TO ACCOUNTS die Klausel IGNORE EDITION CHECK eingefügt wird. Wenn IGNORE EDITION CHECK festgelegt ist, kann die Primärdatenbank in jeder Snowflake-Edition in die angegebenen Konten repliziert werden.

Aktuelle Einschränkungen bei Datenbankreplikationen

  • Aus Freigaben erstellte Datenbanken können nicht repliziert werden.

  • Die Aktualisierungsoperation schlägt fehl, wenn die Primärdatenbank Folgendes enthält:

    • Ereignistabelle

    • Externe Tabelle

Die Replikations- oder Aktualisierungsoperation einer Datenbank schlägt fehl, wenn die Primärdatenbank einen Stream mit einem nicht unterstützten Quellobjekt enthält. Die Operation schlägt auch fehl, wenn das Quellobjekt eines Streams gelöscht wurde.

Nur-Anfügen-Streams werden bei replizierten Quellobjekten nicht unterstützt.

  • Der Befehl CREATE DATABASE … AS REPLICA bietet keine Unterstützung für die WITH TAG-Klausel.

    Diese Klausel wird nicht unterstützt, da die Sekundärdatenbank schreibgeschützt ist. Wenn Ihre Primärdatenbank die WITH TAG-Klausel enthält, entfernen Sie die Klausel, bevor Sie die Sekundärdatenbank erstellen. Um zu überprüfen, ob Ihre Datenbank über die WITH TAG-Klausel verfügt, rufen Sie in Ihrem Snowflake-Konto die Funktion GET_DDL auf und geben die Primärdatenbank im Funktionsargument an. Wenn ein Tag auf der Datenbank gesetzt ist, enthält die Funktionsausgabe eine ALTER DATABASE … SET TAG-Anweisung.

  • Die Replikation von Stagingbereichen und Pipes wird nicht unterstützt. Sie können Stagingbereiche und Pipes mithilfe der Kontoreplikation replizieren. Weitere Informationen dazu finden Sie unter Replikation von Stagingbereichen, Pipes und des Ladeverlaufs.

  • Geheimnisse werden nicht unterstützt. Sie können Geheimnisse mithilfe einer Replikations- oder Failover-Gruppe replizieren.