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 |
|---|---|---|---|
✔ |
Die Replikation einiger Datenbanken wird nicht unterstützt oder die Aktualisierungsoperation kann fehlschlagen. Weitere Informationen dazu finden Sie unter Aktuelle Einschränkungen bei Replikationen. |
||
Sicherheit, API, Benachrichtigung, Speicherung, externer Zugriff [1] |
✔ |
Weitere Beschränkungen und Details zu den unterstützten Typen finden Sie unter Integrationsreplikation. Erfordert Business Critical Edition (oder höher). |
|
✔ |
Erfordert Business Critical Edition (oder höher). |
||
✔ |
Erfordert Business Critical Edition (oder höher). |
||
✔ |
Benachrichtigungen von Ressourcenmonitoren für Benutzer, die keine Administratoren sind, werden repliziert, wenn Sie Erfordert Business Critical Edition (oder höher). |
||
✔ |
|
||
✔ |
Die Replikation von eingehenden Freigaben (Freigaben von Anbietern) wird nicht unterstützt. |
||
✔ |
Erfordert Business Critical Edition (oder höher). |
||
✔ |
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. |
|
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:
Sicherheitsintegrationen der folgenden Typen:
Verbundauthentifizierung und SSO (d. h. SAML2)
SCIM
Snowflake OAuth
External OAuth
Weitere Informationen zu Sicherheitsintegrationen finden Sie unter Replikation von Sicherheitsintegrationen und Netzwerkrichtlinien über mehrere Konten hinweg.
API-Integrationen.
Nachdem Sie API-Integrationen in ein Zielkonto repliziert haben, müssen Sie den replizierten externen Funktionen Zugriff auf den Remotedienst gewähren. Weitere Informationen dazu finden Sie unter Aktualisieren des Remotedienstes für API-Integrationen.
Benachrichtigungsintegrationen der folgenden Typen:
TYPE = EMAIL
TYPE = QUEUE mit DIRECTION = OUTBOUND
TYPE = WEBHOOK
Speicherintegrationen.
Wenn Sie eine Speicherintegration replizieren, müssen Sie in den Zielkonten eine neue Vertrauensstellung für Ihren Cloudspeicher einrichten. Weitere Informationen dazu finden Sie unter Cloudspeicherzugriff für sekundäre Speicherintegrationen konfigurieren.
Integrationen für den externen Zugriff.
Weitere Informationen zu Integrationen für den externen Zugriff finden Sie unter Übersicht über externen Netzwerkzugriff.
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
usersundresource monitorsin derobject_types-Liste für die Replikations- oder Failover-Gruppe enthalten sind, werden die Benachrichtigungseinstellungen für Nicht-Administrator-Benutzer repliziert:Die Liste
notify_userseines Ressourcenmonitors auf Warehouse-Ebene wird in Zielkonten repliziert.E-Mail-Benachrichtigungen für Nicht-Administrator-Benutzer werden an das Zielkonto gesendet.
Wenn
resource monitorsin derobject_types-Liste für die Replikations- oder Failover-Gruppe enthalten ist,usersaber nicht, ist dienotify_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.
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. |
✔ |
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 |
✔ |
|
✔ |
Weitere Informationen zur Replikation von Sicherheitsintegrationen mit Verbund-SSO (d. h. SAML2) finden Sie unter Replikation von Sicherheitsintegrationen und Netzwerkrichtlinien über mehrere Konten hinweg. |
|
✔ |
Weitere Informationen zur Replikation von OAuth-Sicherheitsintegrationen finden Sie unter Replikation von Sicherheitsintegrationen und Netzwerkrichtlinien über mehrere Konten hinweg. |
|
✔ |
Weitere Informationen zur Replikation von OAuth-Sicherheitsintegrationen finden Sie unter Replikation von Sicherheitsintegrationen und Netzwerkrichtlinien über mehrere Konten hinweg. |
|
✔ |
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_typesenthalten).
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.
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.