Einführung in Replikation und Failover über mehrere Konten

Dieses Feature ermöglicht die Replikation von Objekten von einem Quellkonto in ein oder mehrere Zielkonten derselben Organisation. Replizierte Objekte in jedem Zielkonto werden als sekundäre Objekte bezeichnet und sind Replikate der primären Objekte im Quellkonto. Die Replikation wird über verschiedene Regionen und Cloudplattformen hinweg unterstützt.

Unter diesem Thema:

Unterstützung von Replikation und Failover/Failback in den Regionen

Die Replikation wird in allen Snowflake-Regionen auf Amazon Web Services, Google Cloud Platform und Microsoft Azure unterstützt.

Kunden können die Replikation über alle Region innerhalb einer Regionsgruppe hinweg ausführen. Wenn Sie die Replikation zwischen Regionen in verschiedenen Regionsgruppen ausführen möchten (d. h. von einer kommerziellen Snowflake-Region zu einer Snowflake-Region für Regierungsbehörden oder einer Virtual Private Snowflake-Region), wenden Sie sich an den Snowflake-Support.

Replikationsgruppen und Failover-Gruppen

Eine Replikationsgruppe ist eine definierte Sammlung von Objekten in einem Quellkonto, die als Einheit in ein oder mehrere Zielkonten repliziert wird. Replikationsgruppen bieten einen Nur-Lese-Zugriff auf die replizierten Objekte.

Eine Failover-Gruppe ist eine Replikationsgruppe, die auch ein Failover ausführen kann. Eine sekundäre Failover-Gruppe in einem Zielkonto bietet einen Nur-Lese-Zugriff für die replizierten Objekte. Wenn eine sekundäre Failover-Gruppe zur primären Failover-Gruppe heraufgestuft wird, ist Lese- und Schreibzugriff möglich. Jedes in der Liste der zulässigen Konten in einer Failover-Gruppe angegebene Zielkonto kann zur primären Failover-Gruppe heraufgestuft werden.

Replikations- und Failover-Gruppen bieten zeitpunktbezogene Konsistenz für die Objekte im Zielkonto. Die Objekte, die in eine Replikations- oder Failover-Gruppe aufgenommen werden können, sind unter Replizierte Objekte aufgeführt.

Feature-Edition-Matrix für Replikation

Beachten Sie, dass einige Replikationsfeatures nur für die Business Critical Edition (oder höher) verfügbar sind. In der folgenden Tabelle ist die Verfügbarkeit der Replikationsfeatures für jede Snowflake-Edition aufgeführt:

Feature

Standard

Enterprise

Business Critical

VPS

Datenbankreplikation

✔

✔

✔

✔

Freigabereplikation

✔

✔

✔

✔

Replikationsgruppe

✔

✔

✔

✔

Replikation von Kontoobjekten (außer Datenbanken und Freigaben)

✔

✔

Failover-Gruppe

✔

✔

Daten geschützt mit Tri-Secret Secure

✔

✔

Replizierte Objekte

Dieses Feature unterstützt das Replizieren der unten aufgeführten Objekte. Die Replikation von Datenbanken und Freigaben ist für alle Editionen verfügbar. Die Replikation aller anderen Objekte ist nur für die Business Critical Edition (oder höher) verfügbar. Weitere Informationen zur Verfügbarkeit der Features finden Sie unter Feature-Edition-Matrix für Replikation.

Objekt

Typ oder Feature

Repliziert

Anmerkungen

Datenbanken

✔

Die Replikation einiger Datenbanken wird nicht unterstützt oder die Aktualisierungsoperation kann fehlschlagen. Weitere Informationen dazu finden Sie unter Aktuelle Einschränkungen bei Replikationen.

Integrationen

Sicherheit, API, Benachrichtigung, Speicher, Externer Zugriff

✔

Weitere Beschränkungen und Details zu den unterstützten Typen finden Sie unter Integrationsreplikation.

Erfordert Business Critical Edition (oder höher).

Netzwerkrichtlinien

✔

Erfordert Business Critical Edition (oder höher).

Parameter (Kontoebene)

✔

Erfordert Business Critical Edition (oder höher).

Ressourcenmonitore

✔

Benachrichtigungen von Ressourcenmonitoren für Benutzer, die keine Administratoren sind, werden repliziert, wenn Sie users in die Gruppe aufnehmen. Benachrichtigungseinstellungen für Kontoadministratoren werden jedoch nicht repliziert. Weitere Informationen dazu finden Sie unter Replikation der E-Mail-Benachrichtigungseinstellungen des Ressourcenmonitors.

Erfordert Business Critical Edition (oder höher).

Rollen

✔

  • Umfasst Konto und Datenbankrollen.

  • Umfasst Berechtigung, die Rollen erteilt werden, sowie Rollen, die Rollen zugewiesen werden (d. h. Hierarchien von Rollen).

  • Wenn Benutzer und Rollen repliziert werden, werden auch die den Benutzern zugewiesenen Rollen repliziert.

  • Die Berechtigungen REPLICATE und FAILOVER werden nicht repliziert.

  • Erfordert Business Critical Edition (oder höher).

Freigaben

✔

Die Replikation von eingehenden Freigaben (Freigaben von Anbietern) wird nicht unterstützt.

Benutzer

✔

Erfordert Business Critical Edition (oder höher).

Warehouses

✔

Erfordert Business Critical Edition (oder höher).

Datenbankreplikation

Dieses Feature unterstützt das Replizieren von Datenbanken. Ein Snapshot enthält Änderungen an den Objekten und Daten. Wenn roles (Rollen) repliziert werden (in derselben oder einer anderen Replikations- oder Failover-Gruppe), werden bei der Datenbankaktualisierung auch die Berechtigungszuweisungen zur Sekundärdatenbank und zu den Objekten in der Datenbank (Schemas, Tabellen, Ansichten usw.) mit den Rollen im Konto synchronisiert. Weitere Informationen dazu finden Sie unter Berechtigungszuweisungen für Datenbankobjekte.

Die Replikation einiger Datenbanken wird nicht unterstützt oder die Aktualisierungsoperation kann fehlschlagen. Weitere Informationen dazu finden Sie unter Aktuelle Einschränkungen bei Replikationen.

Replizierte Datenbankobjekte

Wenn eine Primärdatenbank repliziert wird, wird ein Snapshot der enthaltenen Datenbankobjekte und Daten in die Sekundärdatenbank übertragen. Einige Datenbankobjekte werden jedoch nicht repliziert. Die folgende Tabelle gibt an, welche Datenbankobjekte in eine Sekundärdatenbank repliziert werden.

Spezifische Informationen zur Verwendung dieser Objekte finden Sie unter Hinweise zur Replikation.

Bemerkung

Objekte, die für die Replikation nicht unterstützt werden, werden bei der Aktualisierungsoperation übersprungen.

Objekt

Typ oder Feature

Repliziert

Anmerkungen

Tabellen

Permanente Tabellen

✔

Transiente Tabellen

✔

Temporäre Tabellen

Automatic Clustering von Clustertabellen

✔

Dynamische Tabellen

✔

Weitere Informationen dazu finden Sie unter Replikation und dynamische Tabellen.

Externe Tabellen

Hybridtabellen

Apache Iceberg™-Tabellen

Tabelleneinschränkungen

✔

Außer wenn ein Fremdschlüssel in der Datenbank auf einen Primär- oder eindeutigen Schlüssel in einer anderen Datenbank verweist. .

Ereignistabellen

Sequenzen

✔

Ansichten

Ansichten

✔

Wenn eine Ansicht auf irgendein Objekt in einer anderen Datenbank verweist (z. B. Tabellenspalten, andere Ansichten, UDFs oder Stagingbereiche), . müssen beide Datenbanken repliziert werden.

Materialisierte Ansichten

✔

Sichere Ansichten

✔

Dateiformate

✔

Stagingbereiche

Stagingbereiche

✔

Nur für Replikations- und Failover-Gruppen unterstützt. Für Datenbankreplikation nicht unterstützt. . Weitere Informationen dazu finden Sie unter Replikation von Stagingbereichen, Pipes und des Ladeverlaufs.

Temporäre Stagingbereiche

Pipes

✔

Nur für Replikations- und Failover-Gruppen unterstützt. Für Datenbankreplikation nicht unterstützt. . Weitere Informationen dazu finden Sie unter Replikation von Stagingbereichen, Pipes und des Ladeverlaufs.

Gespeicherte Prozeduren

✔

Weitere Informationen dazu finden Sie unter Replikation von gespeicherten Prozeduren und benutzerdefinierten Funktionen (UDFs).

Streams

✔

Weitere Informationen dazu finden Sie unter Replikation und Streams.

Aufgaben

✔

Weitere Informationen dazu finden Sie unter Replikation und Aufgaben.

Datenmetrikfunktionen (DMFs)

Data Quality

✔

Weitere Informationen dazu finden Sie unter Replikation von Datenmetrikfunktionen (DMFs).

UDFs

✔

Weitere Informationen dazu finden Sie unter Replikation von gespeicherten Prozeduren und benutzerdefinierten Funktionen (UDFs).

Richtlinien

Aggregationsrichtlinien

✔

Authentifizierungsrichtlinien

✔

Sicherheit auf Spaltenebene (Maskieren)

✔

Weitere Informationen zu Maskierungsrichtlinien, Zeilenzugriffsrichtlinien und Tag-basierte Maskierungsrichtlinien finden Sie unter Hinweise zur Richtlinienreplikation.

Verknüpfungsrichtlinien

✔

Kennwortrichtlinien

✔

Datenschutzrichtlinien

✔

Weitere Informationen dazu finden Sie unter Datenschutzrichtlinien.

Projektionsrichtlinien

✔

Zeilenzugriffsrichtlinien

✔

Sitzungsrichtlinien

✔

Informationen zu Sitzungs-, Kennwort- und Authentifizierungsrichtlinien finden Sie unter Replikations- und Sicherheitsrichtlinien.

Tag-basierte Maskierungsrichtlinien

✔

Tags

Objekt-Tagging

✔

Weitere Informationen zu Tags finden Sie unter Replikation und Tags.

Alerts

✔

Geheimnisse

Geheimnisse für externe API-Authentifizierung

✔

Sie können Geheimnisse mithilfe einer Replikations- oder Failover-Gruppe replizieren. Weitere Informationen dazu finden Sie unter Replikation und Geheimnisse.

Netzwerkregeln

✔

Weitere Informationen zur Replikation von Netzwerkrichtlinien, die Netzwerkregeln verwenden, finden Sie unter Replizieren von Netzwerkrichtlinien.

Klasseninstanzen

CUSTOM_CLASSIFIER

✔

Die Replikation wird für Instanzen der Klasse CUSTOM_CLASSIFIER unterstützt. Instanzen aller anderen Snowflake-Klassen werden nicht repliziert. Eine vollständige Liste der Snowflake-Klassen finden Sie unter Verfügbare Klassen.

Paketrichtlinien

UDF, UDTF, gespeicherte Prozeduren in Python

✔

Wenn für das Quellkonto eine Paketrichtlinie - festgelegt ist, muss die Datenbank, die die Paketrichtlinie enthält, in das Zielkonto in derselben oder einer anderen Replikations- oder Failover-Gruppe repliziert werden, damit die Kontobjekte erfolgreich repliziert werden können. Andernfalls schlägt die Aktualisierungsoperation mit einem Fehler aufgrund verwaister Referenzen fehl.

Datenbankreplikation und -verschlüsselung

Snowflake schützt Metadaten und Datensets im Ruhezustand und bei der Übertragung zwischen Quell- und Zielkonten. Der Kontohauptschlüssel (AMK) verschlüsselt die Schlüsselhierarchie innerhalb des Kontos, wie im hierarchischen Schlüsselmodell gezeigt. Snowflake verschlüsselt replizierte Daten im Zielkonto mithilfe des Kontohauptschlüssels und der Schlüsselhierarchie im Zielkonto, unabhängig davon, ob Sie Tri-Secret Secure im Zielkonto aktivieren.

Wenn Sie Tri-Secret Secure im Zielkonto aktivieren, verwendet Snowflake den zusammengesetzten Hauptschlüssel und die entsprechende Schlüsselhierarchie im Zielkonto, um die Daten zu verschlüsseln. Beachten Sie, dass bei Zielkonten Tri-Secret Secure nicht standardmäßig aktiviert ist. Dieses Feature müssen Sie selbst aktivieren.

Weitere Informationen zur Datenverschlüsselung in Snowflake finden Sie unter Erläuterungen zur End-to-End-Verschlüsselung in Snowflake.

Integrationsreplikation

Die Kontoreplikation unterstützt die Replikation der Integrationen für die folgenden Features:

Replikation von Netzwerkrichtlinien

Dieses Feature unterstützt das Replizieren von Netzwerkrichtlinien.

Weitere Informationen dazu finden Sie unter Replikation von Sicherheitsintegrationen und Netzwerkrichtlinien über mehrere Konten hinweg.

Replikation von Parametern

Dieses Feature unterstützt das Replizieren von Parametern auf Kontoebene und von Objektparametern. Objektparameter werden repliziert, wenn das Objekt in die Replikationsgruppe aufgenommen wird. Wenn zum Beispiel WAREHOUSES repliziert werden, werden Warehouse-spezifische Parameter (z. B. STATEMENT_TIMEOUT_IN_SECONDS) repliziert. Eine vollständige Liste finden Sie unter Objektparameter.

Das Replizieren von Parametern auf Kontoebene umfasst alle Kontoparameter und die für das Konto festgelegten Parameter. Parameter auf Kontoebene (z. B. DATA_RETENTION_TIME_IN_DAYS) werden repliziert, wenn ACCOUNT PARAMETERS in der Liste der Objekttypen einer Replikationsgruppe enthalten ist.

Replikation von Ressourcenmonitoren

Dieses Feature unterstützt das Replizieren von Ressourcenmonitoren einschließlich der Berechtigungen, die Rollen für Ressourcenmonitore erteilt wurden. Ein sekundärer Ressourcenmonitor verwendet denselben Zeitplan für das Zurücksetzen von Kontingenten wie sein primärer Ressourcenmonitor. Wenn beispielsweise das Kontingent des primären Ressourcenmonitors am Ersten des Monats zurückgesetzt wird und der sekundäre Ressourcenmonitor zum ersten Mal am 15. des Monats repliziert wird, wird sein Kontingent am 1. des nächsten Monats zusammen mit dem primären Monitor zurückgesetzt.

Replikation der E-Mail-Benachrichtigungseinstellungen des Ressourcenmonitors

E-Mail-Benachrichtigungseinstellungen für Ressourcenmonitore sind nicht Bestandteil der Replikation des Ressourcenmonitors. E-Mail-Benachrichtigungen für Nicht-Administrator-Benutzer können zusammen mit Ressourcenmonitoren repliziert werden. Allerdings werden die Benachrichtigungseinstellungen des Kontoadministrators derzeit nicht repliziert:

  • Wenn users und resource monitors in der object_types-Liste für die Replikations- oder Failover-Gruppe enthalten sind, werden die Benachrichtigungseinstellungen für Nicht-Administrator-Benutzer repliziert:

  • Wenn resource monitors in der object_types-Liste für die Replikations- oder Failover-Gruppe enthalten ist, users aber nicht, ist die notify_users-Liste eines sekundären Ressourcenmonitors auf Warehouse-Ebene leer.

  • Die Benachrichtigungseinstellungen des Kontoadministrators werden nicht repliziert:

    • Ein Kontoadministrator muss das Aktivieren der E-Mail-Benachrichtigungen in jedem Konto über die Weboberfläche vornehmen.

    • Benachrichtigungen von Ressourcenmonitoren werden an Kontoadministratoren gesendet, wenn diese E-Mail-Benachrichtigungen im Quell- und/oder Zielkonto aktiviert sind.

Rollenreplikation

Dieses Feature unterstützt das Replizieren von Rollen einschließlich der Rollenhierarchien. Rollenobjekte müssen repliziert werden, um Zugriffsrechte zu replizieren. Replizierte Zugriffsrechte sind unter Replikation von Rollen und Berechtigungszuweisungen (unter diesem Thema) aufgeführt.

Bemerkung

Alle Rollen werden repliziert, auch die Rolle ORGADMIN.

Freigabereplikation

Dieses Feature unterstützt das Replizieren von Freigabeobjekten sowie von Zugriffsrechten, die Freigaben für Datenbankobjekte erteilt wurden.

Die Replikation von eingehenden Freigaben (Freigaben von Anbietern) wird nicht unterstützt.

Benutzerreplikation

Dieses Feature unterstützt das Replizieren von Benutzern und deren Eigenschaften in Zielkonten, die folgenden Benutzerauthentifizierungsmethoden sowie das Bereitstellen von Benutzern und Gruppen mit SCIM:

Authentifizierungsmethode

Funktioniert in Zielkonten

Anmerkungen

Kennwort

✔

Kennwort mit MFA (Mehrstufige Authentifizierung)

✔

Benutzer, die im Quellkonto für MFA angemeldet sind, müssen sich für eine Anmeldung in jedem Zielkonto separat für MFA anmelden.

Mehrstufige Authentifizierung (MFA)

✔

Benutzer, die im Quellkonto für MFA angemeldet sind, müssen sich für eine Anmeldung in jedem Zielkonto separat für MFA anmelden.

Schlüsselpaar-Authentifizierung

✔

Verbundauthentifizierung

✔

Weitere Informationen zur Replikation von Sicherheitsintegrationen mit Verbund-SSO (d. h. SAML2) finden Sie unter Replikation von Sicherheitsintegrationen und Netzwerkrichtlinien über mehrere Konten hinweg.

Snowflake OAuth

✔

Weitere Informationen zur Replikation von OAuth-Sicherheitsintegrationen finden Sie unter Replikation von Sicherheitsintegrationen und Netzwerkrichtlinien über mehrere Konten hinweg.

External OAuth

✔

Weitere Informationen zur Replikation von OAuth-Sicherheitsintegrationen finden Sie unter Replikation von Sicherheitsintegrationen und Netzwerkrichtlinien über mehrere Konten hinweg.

SCIM

✔

Weitere Informationen zur Replikation von SCIM-Sicherheitsintegrationen finden Sie unter Replikation von Sicherheitsintegrationen und Netzwerkrichtlinien über mehrere Konten hinweg.

Bemerkung

Wenn USERS- und ROLES-Objekte in ein Zielkonto repliziert werden, sind diese Objekttypen im Zielkonto schreibgeschützt und können nicht geändert werden. Benutzer und Rollen müssen im Quellkonto erstellt und dann in jedes Zielkonto repliziert werden. Weitere Informationen dazu finden Sie unter Replikation und schreibgeschützte Sekundärobjekte.

Warehouse-Replikation

Dieses Feature unterstützt das Replizieren von Warehouses einschließlich der Berechtigungen, die Rollen für Warehouses erteilt wurden (wenn roles repliziert werden). Der Status des primären Warehouses wird nicht repliziert. Warehouses werden im angehaltenen Zustand in jedes Zielkonto repliziert und können dann im Zielkonto fortgesetzt werden.

Replikation von Rollen und Berechtigungszuweisungen

Um für Rollen Berechtigungszuweisungen zu Objekten zu replizieren, müssen die Rollen vom Quellkonto in das Zielkonto repliziert werden. Um Rollen einer Replikations- oder Failover-Gruppe zu replizieren, müssen Sie roles in die Liste object_types aufnehmen. Rollen können sich in einer separaten Replikations- oder Failover-Gruppe befinden, die von den Datenobjekten getrennt ist, für die die Berechtigungen erteilt wurden.

Wenn roles repliziert werden, werden Berechtigungszuweisungen zu Objekten nur in folgenden Fällen in ein Zielkonto repliziert:

  • Die Berechtigung wurde vom Objekteigentümer erteilt oder indirekt über eine Rolle, der die Berechtigung mit dem Parameter WITH GRANT OPTION vom Eigentümer des Objekts erteilt wurde.

  • Sowohl die Rolle des Berechtigungsempfängers als auch die Rolle des Berechtigungsgebers einer Berechtigungszuweisung befinden sich im Zielkonto.

  • Das Objekt wird repliziert (d. h. der Objekttyp ist in der Liste object_types enthalten).

Andernfalls wird die Berechtigungszuweisung für das Objekt nicht repliziert.

Informationen zur Replikation von Sekundärrollen und Sitzungsrichtlinien finden Sie unter Sitzungsrichtlinien mit Sekundärrollen.

Bemerkung

  • Wenn eine Rolle gelöscht wird, die die OWNERSHIP-Berechtigung für eine aktive Pipe im Zielkonto hat, schlägt die Aktualisierungsoperation fehl.

  • Berechtigungen für Replikations- und Failover-Gruppen werden derzeit nicht repliziert. Wenn die REPLICATE- oder FAILOVER-Berechtigung für Replikationsgruppen bzw. Failover-Gruppen erteilt wurde, müssen diese Berechtigungen in den Quellkonten und in den Zielkonten erteilt werden. Weitere Informationen zu diesen Berechtigungen finden Sie unter Replikationsberechtigungen.

Berechtigungszuweisungen für Datenbankobjekte

Wenn roles (Rollen) und databases (Datenbanken) in ein Zielkonto (in derselben oder einer anderen Replikations- oder Failover-Gruppe) repliziert werden, werden bei der Aktualisierung einer Sekundärdatenbank die Berechtigungszuweisungen zur Datenbank und zu den Objekten in der Datenbank (Schemas, Tabellen, Ansichten usw.) mit den vorhandenen Rollen im Zielkonto (d. h. den Rollen, die in das Zielkonto repliziert wurden) synchronisiert. Beachten Sie, dass nur Berechtigungszuweisungen zu Objekten synchronisiert werden, die von der Datenbankreplikation unterstützt werden. Eine Liste der Objekte finden Sie unter Replizierte Datenbankobjekte.

Die Replikation externer Tabellen wird derzeit nicht unterstützt. Infolgedessen werden auch die Berechtigungszuweisungen zu externen Tabellen nicht repliziert:

Zukünftige Berechtigungszuweisungen für Objekte

Wenn Rollen in das Zielkonto repliziert werden, werden zukünftige Berechtigungszuweisungen, die auf Datenbank- oder Schemaebene erteilt wurden, in das Zielkonto repliziert. Dies gilt auch für zukünftige Berechtigungszuweisungen zu Objekten, für die die Replikation nicht unterstützt wird. So wird beispielsweise die Replikation externer Tabellen noch nicht unterstützt, jedoch werden zukünftige Berechtigungszuweisungen für externe Tabellen repliziert. Wenn Sie eine externe Tabelle in einem Zielkonto erstellen, werden die für künftige externe Tabellen erteilten Berechtigungen wie vorgesehen umgesetzt.

Objekterstellung und Eigentümerschaft

Wenn bei der Aktualisierung des Quellkontos in einem Zielkonto neue Objekte erstellt werden, aber die Rollen nicht in das Zielkonto repliziert werden, wird die OWNERSHIP-Berechtigung für die neuen Objekte der Rolle ACCOUNTADMIN zugewiesen.

Falls Rollen in das Zielkonto repliziert werden, wird beim nächsten Replizieren der Rollen die OWNERSHIP-Berechtigung im Zielkonto der gleichen Rolle zugewiesen, welche die OWNERSHIP-Berechtigung im Quellkonto hatte. Rollen können gleichzeitig mit den neuen Objekten in das Zielkonto repliziert werden, wenn sich Objekte und Rollen in der gleichen Replikationsgruppe (oder Failover-Gruppe) befinden.

Berechtigungszuweisungen für Freigaben

Um ein sicheres Data Sharing zu ermöglichen, werden für Freigaben Berechtigungszuweisungen zu Objekten repliziert, auch wenn roles nicht in Zielkonten repliziert werden. Dieser Abschnitt enthält Informationen darüber, wie für Freigaben Berechtigungen zu Objekten repliziert werden.

Wenn roles vom Quellkonto in das Zielkonto repliziert werden, werden Berechtigungen für Objekte auf Freigaben in folgenden Fällen repliziert:

  • Die Rolle des Berechtigungsgebers existiert im Zielkonto oder

  • Die Rolle des Berechtigungsgebers im Quellkonto hat die OWNERSHIP-Berechtigung für das primäre Objekt.

Wenn roles nicht vom Quellkonto in das Zielkonto repliziert werden, dann gilt Folgendes:

  • Für Freigaben werden Berechtigungszuweisungen zu Objekten repliziert.

  • Die Rolle des Berechtigungsgebers für Berechtigungszuweisungen zu replizierten Objekten für Freigaben ist die Rolle mit der OWNERSHIP-Berechtigung für das Objekt.

Benutzer, der Objekte in einem Zielkonto aktualisiert

Ein Benutzer, der den Befehl ALTER FAILOVER GROUP … REFRESH ausführt, um Objekte in einem Zielkonto aus einem Quellkonto zu aktualisieren, muss eine Rolle mit der Berechtigung REPLICATE für die Failover-Gruppe haben. Snowflake schützt diesen Benutzer im Zielkonto, indem folgende Szenarios fehlschlagen:

  • Wenn der Benutzer im Quellkonto nicht vorhanden ist, schlägt die Aktualisierungsoperation fehl.

  • Wenn der Benutzer im Quellkonto vorhanden ist, ihm aber keine Rolle mit der Berechtigung REPLICATE zugewiesen wurde, schlägt die Aktualisierungsoperation fehl.

Replikationsplan

Als Best Practice empfiehlt Snowflake das Erstellen eines Zeitplans für automatische Aktualisierungen unter Verwendung des Parameters REPLICATION_SCHEDULE. Der Zeitplan kann beim Erstellen einer neuen Replikations- oder Failover-Gruppe mit CREATE <Objekt> oder später (mit ALTER <Objekt>) definiert werden.

Wenn Sie eine sekundäre Replikations- oder Failover-Gruppe erstellen, führt Snowflake automatisch eine erstmalige Aktualisierung aus. Die nächste Aktualisierung wird dann auf Grundlage des Startzeitpunkts der vorherigen Aktualisierung und des Planungsintervalls oder des nächsten gültigen Zeitpunkts auf Grundlage des Cron-Ausdrucks geplant. Wenn beispielsweise das Aktualisierungsintervall 10 Minuten beträgt und die vorherige Aktualisierungsoperation (entweder eine geplante Aktualisierung oder eine manuell ausgelöste Aktualisierung) um 12:01 Uhr beginnt, ist die nächste Aktualisierung für 12:11 Uhr geplant.

Snowflake stellt sicher, dass zu jedem Zeitpunkt nur eine Aktualisierung ausgeführt wird. Wenn eine Aktualisierung noch ausgeführt wird, wenn die nächste Aktualisierung geplant ist, wird der Start der nächsten Aktualisierung so lange verzögert, bis die in Ausführung befindliche Aktualisierung abgeschlossen ist. Wenn z. B. eine Aktualisierung so geplant ist, dass sie jede Stunde 15 Minuten nach der vollen Stunde ausgeführt wird, und die vorherige Aktualisierung um 12:16 abgeschlossen ist, wird die nächste Aktualisierung so geplant, dass die Ausführung nach Abschluss der vorhergehende Aktualisierung erfolgt.

Bemerkung

Automatisch geplante Aktualisierungsoperationen werden unter Verwendung der Rolle mit der Berechtigung OWNERSHIP für die Replikations- oder Failover-Gruppe ausgeführt. Wenn eine geplante Aktualisierungsoperation aufgrund unzureichender Berechtigungen fehlschlägt, erteilen Sie der Rolle mit der Berechtigung OWNERSHIP für die Gruppe die erforderlichen Berechtigungen.

Geplante Replikation anhalten und fortsetzen

Eine sekundäre Failover-Gruppe kann nicht zur primären Gruppe heraufgestuft werden, wenn gerade eine Aktualisierung ausgeführt wird. Um einen ordnungsgemäßes Failover sicherzustellen, halten Sie die geplante Replikation im Zielkonto an. Nach Abschluss des Failovers setzen Sie die geplante Replikation fort. Weitere Informationen dazu finden Sie unter ALTER FAILOVER GROUP.

Replikation in Konten mit niedrigeren Editionen

Wenn eine der folgenden Bedingungen erfüllt ist, zeigt Snowflake eine Fehlermeldung an:

  • Eine primäre Replikationsgruppe, die nur Datenbank- und/oder Freigabeobjekte enthält, befindet sich in einem Business Critical-Konto (oder höher), aber eines oder mehrere der zur Replikation genehmigten Konten weisen niedrigere Editionen auf. Die Business Critical Edition ist für Snowflake-Konten mit äußerst sensiblen Daten vorgesehen.

  • Eine primäre Replikations- oder Failover-Gruppe mit beliebigen Objekttypen befindet sich in einem Business Critical-Konto (oder höher), und es besteht eine unterzeichnete Geschäftspartner-Vereinbarung zur Speicherung von PHI-Daten in dem Konto gemäß HIPAA- und HITRUST CSF-Vorschriften. Allerdings besteht für eines oder mehrere der zur Replikation aktivierten Konten keine solche Vereinbarung, unabhängig davon, ob es sich um Business Critical-Konten (oder höhere) 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 (ein Benutzer mit der Rolle ACCOUNTADMIN) oder ein Benutzer mit einer Rolle mit CREATE REPLICATION GROUP/CREATE FAILOVER GROUP- oder OWNERSHIP-Berechtigung kann dieses Standardverhalten überschreiben, indem beim Ausführen der CREATE <Objekt>- oder ALTER <Objekt>-Anweisung die IGNORE EDITION CHECK-Klausel eingefügt wird. Wenn IGNORE EDITION CHECK festgelegt ist, kann in diesen spezifischen Szenarios die primäre Replikations- oder Failover-Gruppe in die angegebenen Konten mit niedrigerer Snowflake-Edition repliziert werden.

Bemerkung

Failover-Gruppen können nur in einem Konto mit Business Critical Edition (oder höher) erstellt werden. Daher können Failover-Gruppen auch nur in ein Konto mit Business Critical Edition (oder höher) repliziert werden.

Aktuelle Einschränkungen bei Replikationen

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

  • Aktualisierungsoperationen schlagen 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.

Bemerkung

Die Datenbankreplikation funktioniert nicht für Task-Graphen, wenn das Diagramm einer anderen Rolle gehört als der Rolle, die die Replikation durchführt.

Sprache: Deutsch