Hinweise zur Replikation

Unter diesem Thema wird das Verhalten bestimmter Snowflake-Features in Sekundärdatenbanken und Objekten beim Replizieren mit Replikations- oder Failover-Gruppen oder bei der Datenbankreplikation beschrieben, und es werden allgemeine Hinweise zur Verwendung replizierter Objekte und Daten bereitgestellt.

Wenn Sie zuvor die Datenbankreplikation für einzelne Datenbanken mit dem Befehl ALTER DATABASE … ENABLE REPLICATION TO ACCOUNTS aktiviert haben, finden Sie unter Hinweise zur Datenbankreplikation zusätzliche Hinweise speziell zur Datenbankreplikation.

Unter diesem Thema:

Einschränkungen für Replikationsgruppen und Failover-Gruppen

In den folgenden Abschnitten werden die Einschränkungen beim Hinzufügen von Kontoobjekten, Datenbanken und Freigaben zu Replikations- und Failover-Gruppen erläutert.

Datenbank- und Freigabeobjekte

Die folgenden Einschränkungen gelten für Datenbank- und Freigabeobjekte:

  • Ein Objekt kann nur in genau einer Failover-Gruppe enthalten sein.

  • Ein Objekt kann in mehreren Replikationsgruppen enthalten sein, solange jede Gruppe in ein anderes Zielkonto repliziert wird.

  • Ein Objekt kann nicht sowohl in einer Failover-Gruppe als auch in einer Replikationsgruppe enthalten sein.

  • Sekundäre (Replikat-)Objekte können nicht zu einer primären Replikations- oder Failover-Gruppe hinzugefügt werden.

Sie können nur ausgehende Freigaben replizieren. Die Replikation von eingehenden Freigaben (Freigaben von Anbietern) wird nicht unterstützt.

Kontoobjekte

Ein Konto kann nur genau eine Replikations- oder Failover-Gruppe haben, die neben Datenbanken und Freigaben auch andere Kontoobjekte enthält.

Replikationsberechtigungen

In diesem Abschnitt werden die Replikationsberechtigungen beschrieben, die Rollen erteilt werden können, um die Operationen festzulegen, die Benutzer auf Replikations- und Failover-Gruppenobjekten im System ausführen können. Die Syntax des Befehls GRANT finden Sie unter GRANT <Berechtigungen>.

Bemerkung

Bei der Datenbankreplikation kann nur ein Benutzer mit der Rolle ACCOUNTADMIN Datenbankreplikation und Failover aktivieren und verwalten. Weitere Informationen zu den erforderlichen Berechtigungen für die Datenbankreplikation finden Sie in der Tabelle mit den erforderlichen Berechtigungen unter Schritt 6: Aktualisieren einer Sekundärdatenbank nach einem Zeitplan.

Berechtigung

Objekt

Verwendung

Anmerkungen

OWNERSHIP

Replikationsgruppe

Failover-Gruppe

Ermöglicht das Löschen und Ändern eines Objekts sowie das Zuweisen und Entziehen des Zugriffs auf das Objekt.

Kann durch folgende Rollen erteilt werden:

Rolle ACCOUNTADMIN oder

Rolle, die über MANAGE GRANTS-Berechtigung verfügt oder

Rolle, die über OWNERSHIP-Berechtigung für die Gruppe verfügt

CREATE REPLICATION GROUP

Konto

Ermöglich das Erstellen von Replikationsgruppen.

Muss von der Rolle ACCOUNTADMIN gewährt werden.

CREATE FAILOVER GROUP

Konto

Ermöglicht das Erstellen von Failover-Gruppen.

Muss von der Rolle ACCOUNTADMIN gewährt werden.

FAILOVER

Failover-Gruppe

Ermöglicht das Heraufstufen einer sekundären Failover-Gruppe zur primären Failover-Gruppe.

Kann von einer Rolle mit OWNERSHIP-Berechtigung für die Gruppe zugewiesen oder entzogen werden.

REPLICATE

Replikationsgruppe

Failover-Gruppe

Ermöglicht das Aktualisieren einer sekundären Gruppe.

Kann von einer Rolle mit OWNERSHIP-Berechtigung für die Gruppe zugewiesen oder entzogen werden.

MODIFY

Replikationsgruppe

Failover-Gruppe

Ermöglicht das Ändern der Einstellungen oder Eigenschaften eines Objekts.

Kann von einer Rolle mit OWNERSHIP-Berechtigung für die Gruppe zugewiesen oder entzogen werden.

MONITOR

Replikationsgruppe

Failover-Gruppe

Ermöglicht das Anzeigen von Details zu einem Objekt.

Kann von einer Rolle mit OWNERSHIP-Berechtigung für die Gruppe zugewiesen oder entzogen werden.

Eine Anleitung zum Erstellen einer kundenspezifischen Rolle mit einer bestimmten Gruppe von Berechtigungen finden Sie unter Erstellen von kundenspezifischen Rollen.

Allgemeine Informationen zu Rollen und Berechtigungen zur Durchführung von SQL-Aktionen auf sicherungsfähigen Objekten finden Sie unter Übersicht zur Zugriffssteuerung.

Replikation und Referenzen über Replikationsgruppen hinweg

Objekte in einer Replikationsgruppe (oder Failover-Gruppe), die verwaiste Referenzen (d. h. Referenzen auf Objekte in einer anderen Replikations- oder Failover-Gruppe) haben, können unter Umständen erfolgreich in ein Zielkonto repliziert werden. Wenn die Replikationsoperation zu einem Verhalten im Zielkonto führt, das mit dem Verhalten übereinstimmt, das im Quellkonto auftreten kann, ist die Replikation erfolgreich.

Wenn beispielsweise eine Spalte in einer Tabelle der Failover-Gruppe fg_a auf eine Sequenz in der Failover-Gruppe fg_b verweist, ist die Replikation für beide Gruppen erfolgreich. Wenn fg_a vor fg_b repliziert wird, werden (nach dem Failover) Einfügeoperationen in die Tabelle, die auf die Sequenz verweist, fehlschlagen, falls fg_b noch nicht repliziert wurde. Dieses Verhalten kann bei einem Quellkonto auftreten. Wenn eine Sequenz in einem Quellkonto gelöscht wird, werden Einfügeoperationen in einer Tabelle mit einer Spalte, die auf die gelöschte Sequenz verweist, fehlschlagen.

Wenn es sich bei der verwaisten Referenz um eine Sicherheitsrichtlinie handelt, die Daten schützt, muss die Replikationsgruppe (oder Failover-Gruppe) mit der Sicherheitsrichtlinie vor jeder Replikationsgruppe repliziert werden, die Objekte enthält, die auf die Richtlinie verweisen.

Achtung

Aktualisierungen von Sicherheitsrichtlinien, die Daten in separaten Replikations- oder Failover-Gruppen schützen, können zu Inkonsistenzen führen und sollten daher mit Vorsicht ausgeführt werden.

Für Datenbankobjekte können Sie Objektabhängigkeiten in der Account Usage-Ansicht OBJECT_DEPENDENCIES anzeigen.

Streams

Verwaiste Referenzen für Streams können dazu führen, dass die Replikation mit der folgenden Fehlermeldung fehlschlägt:

Primary database: the source object ''<object_name>'' for this stream ''<stream_name>'' is not included in the replication group.
Stream replication does not support replication across databases in different replication groups. Please see Streams Documentation
https://docs.snowflake.com/en/user-guide/account-replication-considerations#replication-and-streams for options.
Copy

So vermeiden Sie Fehler durch verwaiste Referenzen:

  • Die Primärdatenbank muss sowohl den Stream als auch dessen Basisobjekt enthalten oder

  • Die Datenbank, die den Stream enthält, und die Datenbank, die das vom Stream referenzierte Basisobjekt enthält, müssen in derselben Replikations- oder Failover-Gruppe enthalten sein.

Netzwerkrichtlinien

Verwaiste Referenzen in Netzwerkrichtlinien können dazu führen, dass die Replikation mit der folgenden Fehlermeldung fehlschlägt:

Dangling references in the snapshot. Correct the errors before refreshing again.
The following references are missing (referred entity <- [referring entities])
Copy

Um verwaiste Referenzen zu vermeiden, geben Sie beim Ausführen des CREATE- oder ALTER-Befehls für die Replikations- oder Failover-Gruppe die folgenden Objekttypen in der Liste OBJECT_TYPES an:

  • Wenn eine Netzwerkrichtlinie eine Netzwerkregel verwendet, geben Sie die Datenbank an, die das Schema enthält, in dem die Netzwerkregel erstellt wurde.

  • Wenn dem Konto eine Netzwerkrichtlinie zugeordnet ist, nehmen Sie NETWORK POLICIES und ACCOUNT PARAMETERS in die Liste OBJECT_TYPES auf.

  • Wenn eine Netzwerkrichtlinie einem Benutzer zugeordnet ist, fügen Sie NETWORK POLICIES und USERS in die Liste OBJECT_TYPES ein.

Weitere Details dazu finden Sie unter Replizieren von Netzwerkrichtlinien.

Geheimnisse

Weitere Details dazu finden Sie unter Replikation und Geheimnisse.

Replikation und schreibgeschützte Sekundärobjekte

Alle Sekundärobjekte in einem Zielkonto, einschließlich sekundäre Datenbanken und Freigaben, sind schreibgeschützt. Änderungen an replizierten Objekten oder Objekttypen können nicht lokal in einem Zielkonto vorgenommen werden. Wenn beispielsweise der Objekttyp USERS von einem Quellkonto in ein Zielkonto repliziert wird, können im Zielkonto keine neuen Benutzer erstellt oder geändert werden.

Neue, lokale Datenbanken und Freigaben können aber in einem Zielkonto erstellt und geändert werden. Wenn auch ROLES in das Zielkonto repliziert werden, können in diesem Zielkonto keine neuen Rollen erstellt oder geändert werden. Daher können einer Rolle keine Berechtigungen für ein sekundäres Objekt im Zielkonto erteilt (oder entzogen) werden. Allerdings können einer Sekundärrolle Berechtigungen für lokale Objekte (z. B. Datenbanken, Freigaben oder Replikations- oder Failover-Gruppen), die im Zielkonto erstellt wurden, erteilt (oder entzogen) werden.

Replikation und Objekte in Zielkonten

Wenn Sie Kontoobjekte wie Benutzer und Rollen in Ihrem Zielkonto auf andere Weise als durch Replikation (z. B. mithilfe von Skripten) erstellen, haben diese Benutzer und Rollen standardmäßig keine globale ID. Wenn ein Zielkonto vom Quellkonto aus aktualisiert wird, führt die Aktualisierungsoperation zum Löschen aller Kontoobjekte der Typen in der OBJECT_TYPES-Liste des Zielkontos, die keine globale ID haben.

Bemerkung

Die erste Aktualisierungsoperation zum Replizieren von USERS oder ROLES kann zu einem Fehler führen. Dies soll verhindern, dass Daten und Metadaten, die Benutzern und Rollen zugeordnet sind, versehentlich gelöscht werden. Weitere Informationen zu den Umständen, die bestimmen, ob diese Objekttypen gelöscht werden oder die Aktualisierungsoperation fehlschlägt, finden Sie unter Erstmalige Replikation von Benutzern und Rollen.

Informationen dazu, wie Sie das Löschen dieser Objekte verhindern können, finden Sie unter Globale IDs auf Objekte anwenden, die von Skripten in Zielkonten erstellt wurden.

Replikation und Sicherheitsrichtlinien

Die Datenbank, die eine Sicherheitsrichtlinie und die Referenzen (d. h. Zuweisungen) enthält, kann mithilfe von Replikations- und Failover-Gruppen repliziert werden. Sicherheitsrichtlinien umfassen:

Wenn Sie die Datenbankreplikation verwenden, finden Sie weitere Informationen unter Datenbankreplikation und Sicherheitsobjekte.

Kennwort- und Sitzungsrichtlinien

Kennwort- und Sitzungsrichtlinienreferenzen für Benutzer werden repliziert, wenn in einer Replikationsgruppe oder Failover-Gruppe die Datenbank, die die Richtlinie enthält (ALLOWED_DATABASES = policy_db), und USERS angegeben werden.

Wenn entweder die Richtliniendatenbank oder die Benutzer bereits in ein Zielkonto repliziert wurden, aktualisieren Sie die Replikations- oder Failover-Gruppe im Quellkonto, um die Datenbanken und Objekttypen aufzunehmen, die für eine erfolgreiche Replikation der Richtlinie erforderlich sind. Führen Sie dann eine Aktualisierungsoperation aus, um das Zielkonto zu aktualisieren.

Wenn auf Benutzerebene keine Richtlinien verwendet werden, muss USERS nicht in die Replikations- oder Failover-Gruppe aufgenommen werden.

Bemerkung

Die Richtlinie muss sich in demselben Konto befinden wie die Richtlinienzuweisung auf Kontoebene und die Richtlinienzuweisung auf Benutzerebene.

Wenn Sie eine Sitzungs- oder Kennwortrichtlinie für das Konto oder für einen Benutzer im Konto festgelegt haben und Sie die Replikations- oder Failover-Gruppe nicht aktualisieren, sodass die Datenbank policy_db, die die Richtlinie und USERS enthält, hinzugefügt wird, tritt im Zielkonto eine verwaiste Referenz auf. In diesem Fall bedeutet eine verwaiste Referenz, dass Snowflake die Richtlinie im Zielkonto nicht finden kann, weil der vollqualifizierte Name der Richtlinie auf die Datenbank im Quellkonto verweist. Folglich müssen das Zielkonto oder die Benutzer des Zielkontos die Sitzungsrichtlinie oder die Kennwortrichtlinie nicht einhalten.

Um eine Sicherheitsrichtlinie erfolgreich zu replizieren, prüfen Sie also vorher, ob die Replikations- oder Failover-Gruppe auch tatsächlich die Objekttypen und Datenbanken enthält, die erforderlich sind, um eine verwaiste Referenz zu verhindern.

Replikation und Geheimnisse

Sie können das Geheimnis nur mithilfe einer Replikations- oder Failover-Gruppe replizieren. Geben Sie in einer einzigen Replikations- oder Failover-Gruppe die Datenbank an, die das Geheimnis enthält, die Datenbank, die die UDFs oder Prozeduren enthält, die auf das Geheimnis verweisen, sowie die Integrationen, die auf das Geheimnis verweisen.

Wenn sich die Datenbank, die das Geheimnis enthält, in einer Replikations- oder Failover-Gruppe befindet, und die Integration, die auf das Geheimnis verweist, in einer anderen Replikations- oder Failover-Gruppe, passiert Folgendes:

  • Wenn Sie zuerst die Integration und dann das Geheimnis replizieren, ist die Operation erfolgreich: Alle Objekte werden repliziert, und es gibt keine verwaisten Referenzen.

  • Wenn Sie das Geheimnis vor der Integration replizieren und das Geheimnis nicht bereits im Zielkonto vorhanden ist, wird im Zielkonto ein „Platzhaltergeheimnis“ hinzugefügt, um eine verwaiste Referenz zu verhindern. Snowflake ordnet das Platzhaltergeheimnis der Integration zu.

    Nachdem Sie die Gruppe, die die Integration enthält, repliziert haben, aktualisiert Snowflake bei der nächsten Aktualisierungsoperation auf der Gruppe, die das Geheimnis enthält, das Zielkonto, um das Platzhaltergeheimnis durch das Geheimnis zu ersetzen, auf das in der Integration verwiesen wird.

  • Wenn Sie das Geheimnis replizieren, aber die Integration nicht von account1 nach account2 replizieren, funktioniert die Integration im Zielkonto (account2) nicht, da es keine Integration zur Verwendung des Geheimnisses gibt. Wenn Sie ein Failover ausführen und das Zielkonto zum Quellkonto heraufgestuft wird, funktioniert die Integration nicht.

    Wenn Sie entscheiden, ein Failover auszuführen, um account1 zum Quellkonto zu machen, stimmen Geheimnis und Integrationsreferenzen überein und das Platzhaltergeheimnis wird nicht verwendet. Auf diese Weise können Sie die Sicherheitsintegration und das Geheimnis, das die Anmeldeinformationen enthält, verwenden, da die Objekte gegenseitig aufeinander verweisen können.

Replikation und Klonen

Geklonte Objekte werden physisch und nicht logisch in sekundäre Datenbanken repliziert. Das heißt, geklonte Tabellen einer Standarddatenbank tragen nicht zum gesamten Datenspeicher bei, es sei denn, DML-Operationen ändern die auf dem Klon vorhandene Daten oder fügen Daten hinzu. Wenn jedoch eine geklonte Tabelle in eine sekundäre Datenbank repliziert wird, werden auch die physischen Daten repliziert, wodurch sich die Datenspeichernutzung für Ihr Konto erhöht.

Replikation und Automatic Clustering

In einer Primärdatenbank überwacht Snowflake geclusterte Tabellen mithilfe von Automatic Clustering und gruppiert sie nach Bedarf neu. Im Rahmen einer Aktualisierungsoperation werden gruppierte Tabellen mit der aktuellen Sortierung der Tabellenmikropartitionen in eine sekundäre Datenbank repliziert. Daher wird in der gruppierten Tabelle der sekundären Datenbank kein Reclustering ausgeführt, da dies redundant wäre.

Wenn eine sekundäre Datenbank gruppierte Tabellen enthält und die Datenbank zur primären Datenbank heraufgestuft wird, beginnt Snowflake mit dem Automatic Clustering der Tabellen in dieser Datenbank, während gleichzeitig die Überwachung gruppierter Tabellen in der bisherigen primären Datenbank ausgesetzt wird.

Informationen zu Automatic Clustering für materialisierte Ansichten finden Sie unter Replikation und materialisierte Ansichten (unter diesem Thema).

Replikation und große Tabellen mit hohen Änderungsraten

Wenn eine oder mehrere Zeilen einer Tabelle aktualisiert oder gelöscht werden, werden alle betroffenen Mikropartitionen, die diese Daten in einer Primärdatenbank speichern, neu erstellt und müssen mit Sekundärdatenbanken synchronisiert werden. Bei großen Tabellen mit hoher Änderungsrate können erhebliche Replikationskosten entstehen.

Für großen Tabellen mit hoher Änderungsrate, bei denen erhebliche Replikationskosten anfallen, können die Auswirkungen wie folgt abgeschwächt werden:

  • Verringern Sie die Häufigkeit der Replikation für alle Primärdatenbanken, in denen solche Tabellen gespeichert sind.

  • Ändern Sie Ihr Datenmodell, um die Änderungsrate zu verringern.

Weitere Informationen dazu finden Sie unter Verwalten der Kosten für große Tabellen mit hoher Änderungsrate.

Replikation und Time Travel

Time Travel- und Fail-safe-Daten einer Sekundärdatenbank werden unabhängig verwaltet und nicht von einer Primärdatenbank repliziert. Das Abfragen von Tabellen und Ansichten in einer Sekundärdatenbank mithilfe von Time Travel kann andere Ergebnisse liefern als das Ausführen derselben Abfrage in der Primärdatenbank.

Historische Daten

Historische Daten, die in einer Primärdatenbank mithilfe von Time Travel abgefragt werden können, werden nicht in Sekundärdatenbanken repliziert.

Angenommen, Daten werden alle 10 Minuten mit Snowpipe kontinuierlich in eine Tabelle geladen, und eine sekundäre Datenbank wird jede Stunde aktualisiert. Die Aktualisierungsoperation repliziert nur die neueste Version der Tabelle. Während jede stündliche Version der Tabelle im Aufbewahrungsfenster zur Abfrage mit Time Travel verfügbar ist, ist keine der iterativen Versionen innerhalb jeder Stunde (die einzelnen Snowpipe-Ladevorgänge) verfügbar.

Datenaufbewahrungsfrist

Die Datenaufbewahrungsfrist für Tabellen einer Sekundärdatenbank beginnt, wenn die Sekundärdatenbank mit den in Tabellen der Primärdatenbank geschriebenen DML-Operationen (d. h. Ändern oder Löschen von Daten) aktualisiert wird.

Bemerkung

Der Parameter DATA_RETENTION_TIME_IN_DAYS für die Datenaufbewahrungsfrist wird nur für Datenbankobjekte der Sekundärdatenbank repliziert, nicht für die Datenbank selbst. Weitere Informationen zur Parameterreplikation finden Sie unter Parameter.

Replikation und materialisierte Ansichten

In einer Primärdatenbank führt Snowflake eine automatische Hintergrundwartung für materialisierte Ansichten durch. Wenn sich eine Basistabelle ändert, werden alle auf der Tabelle definierten materialisierten Ansichten von einem Hintergrunddienst aktualisiert, der von Snowflake bereitgestellte Computeressourcen nutzt. Wenn das Automatic Clustering für eine materialisierte Ansicht aktiviert ist, wird die Ansicht außerdem überwacht und bei Bedarf in einer Primärdatenbank erneut geclustert.

Eine Aktualisierungsoperation repliziert die materialisierte Ansicht Definitionen in eine Sekundärdatenbank. Die materialisierte Ansicht Daten werden nicht repliziert. Die automatische Hintergrundwartung von materialisierten Ansichten in einer Sekundärdatenbank ist standardmäßig aktiviert. Wenn für eine materialisierte Ansicht in einer Primärdatenbank Automatic Clustering aktiviert wird, wird dabei auch das automatische Überwachen und das Reclustering der materialisierten Ansicht in der Sekundärdatenbank aktiviert.

Bemerkung

Die Gebühren für die automatische Hintergrundsynchronisierung von materialisierten Ansichten werden jedem Konto in Rechnung gestellt, das eine Sekundärdatenbank enthält.

Replikation und externe Tabellen

Externe Tabellen in einer Primärdatenbank

Externe Tabellen in einer Primärdatenbank führen derzeit dazu, dass die Replikations- oder Aktualisierungsoperation mit der folgenden Fehlermeldung fehlschlägt:

003906 (55000): SQL execution error:
Primary database contains an external table '<database_name>'. Replication of a database with external table is not supported
Copy

Um diesen Fehler zu vermeiden, verschieben Sie die externen Tabellen in eine separate Datenbank, die nicht repliziert wird. Wenn Sie Ihre Datenbanken auf ein anderes Konto migrieren, können Sie alternativ die primäre Datenbank klonen, die externe Tabelle aus dem Klon löschen und dann die geklonte Datenbank replizieren. Nachdem Sie die Sekundärdatenbank im Zielkonto zur Primärdatenbank heraufgestuft haben, müssten Sie die externen Tabellen in der Datenbank neu erstellen.

Externe Tabellen in einer Sekundärdatenbank

Externe Tabellen können in einer Sekundärdatenbank existieren, wenn diese zu einem früheren Zeitpunkt die Primärdatenbank war und die externen Tabellen in dieser Zeit erstellt wurden. Sobald eine andere Datenbank zur Primärdatenbank heraufgestuft wird, wird die bisherige Primärdatenbank wieder zur Sekundärdatenbank. Externe Tabellen in einer Sekundärdatenbank führen derzeit dazu, dass die Aktualisierungsoperation mit dem folgenden Fehler fehlschlägt:

003958 (55000): SQL execution error:
Secondary database contains an external table '<table_name>'. Replication of a database with external table is not supported.
Copy

Um diesen Fehler zu vermeiden, verschieben Sie die externe Tabelle in eine separate Datenbank, bei der es sich nicht um eine replizierte Sekundärdatenbank handelt.

Replikation und dynamische Tabellen

Die Replikation dynamischer Tabellen verhält sich unterschiedlich, je nachdem, ob die Primärdatenbank, die die dynamische Tabelle enthält, in einer Replikationsgruppe oder in einer Failover-Gruppe repliziert wird.

Dynamische Tabellen und Replikationsgruppen

Eine Datenbank, die eine dynamische Tabelle enthält, kann mithilfe einer Replikationsgruppe repliziert werden. Die Basisobjekte, von denen sie abhängt, müssen sich nicht in derselben Replikationsgruppe befinden.

Sekundäre Objekte sind im Zielkonto schreibgeschützt. Wenn eine sekundäre Replikationsgruppe in einem Zielkonto gelöscht wird, sind die Datenbanken, die in der Gruppe enthalten waren, nicht mehr schreibgeschützt. Alle dynamischen Tabellen, die in einer Replikationsgruppe enthalten sind, bleiben jedoch schreibgeschützt, auch wenn die sekundäre Gruppe im Zielkonto gelöscht wird. Auf diesen schreibgeschützten dynamischen Tabellen können keine DML-Befehle oder Aktualisierungen ausgeführt werden.

Dynamische Tabellen und Failover-Gruppen und Datenbankreplikation

Eine Datenbank, die eine dynamische Tabelle enthält, kann mithilfe einer Failover-Gruppe repliziert werden. Die Basisobjekte, von denen sie abhängt, müssen in der gleichen Failover-Gruppe enthalten sein. Andernfalls entsteht während der Aktualisierungsoperation eine verwaiste Referenz mit der folgenden Fehlermeldung:

002749 (55000): SQL execution error: Dynamic table <dt_name> has dependencies that are missing in the replication membership: <dependency_table_name>

Dasselbe gilt, wenn die dynamische Tabelle in einer Datenbank mittels Datenbankreplikation repliziert wird. Die Basisobjekte, von denen die dynamische Tabelle abhängt, müssen in derselben Datenbank enthalten sein, um einen Fehler aufgrund verwaister Referenzen zu vermeiden.

Sekundäre dynamische Tabellen sind schreibgeschützt und werden nicht aktualisiert. Nachdem ein Failover stattgefunden hat und eine sekundäre dynamische Tabelle zur primären dynamischen Tabelle heraufgestuft wurde, ist die erste Aktualisierung eine Neuinitialisierung, gefolgt von inkrementellen Aktualisierungen, wenn die dynamische Tabelle für eine inkrementelle Aktualisierung der Daten konfiguriert ist.

Replikation und Snowpipe Streaming

Eine Tabelle, die von Snowpipe Streaming in einer Primärdatenbank gefüllt wird, wird in die Sekundärdatenbank in einem Zielkonto repliziert.

In der Primärdatenbank werden Tabellen erstellt und Zeilen über Kanäle eingefügt. Mithilfe von Offset-Tokens wird der Erfassungsfortschritt verfolgt. Eine Aktualisierungsoperation repliziert das Tabellenobjekt, die Tabellendaten und die mit der Tabelle verbundenen Kanal-Offsets von der Primärdatenbank in die Sekundärdatenbank.

Vermeiden von Datenverlusten

Um Datenverluste bei einem Failover zu vermeiden, muss die Datenaufbewahrungsdauer für erfolgreich eingefügte Zeilen in Ihrer Upstream-Datenquelle größer sein als die Replikationshäufigkeit. Wenn Daten in die Tabelle einer Primärdatenbank eingefügt werden und ein Failover stattfindet, bevor die Daten in die Sekundärdatenbank repliziert werden können, müssen dieselben Daten in die Tabelle der neu heraufgestuften Primärdatenbank eingefügt werden. Nachfolgend ein Beispielszenario:

  1. Die Tabelle t1 in der Primärdatenbank repl_db wird über Snowpipe Streaming und den Kafka-Konnektor mit Daten gefüllt.

  2. Der Wert von offsetToken ist 100 für Kanal 1 und 100 für Kanal 2 für t1 in der Primärdatenbank.

  3. Eine Aktualisierungsoperation wird im Zielkonto erfolgreich abgeschlossen.

  4. Der Wert von offsetToken ist 100 für Kanal 1 und 100 für Kanal 2 für t1 in der Sekundärdatenbank.

  5. Weitere Zeilen werden in t1 in der Primärdatenbank eingefügt.

  6. Der Wert von offsetToken ist jetzt 200 für Kanal 1 und 200 für Kanal 2 für t1 in der Primärdatenbank.

  7. Ein Failover findet statt, bevor die zusätzlichen Zeilen und neuen Kanal-Offsets in die Sekundärdatenbank repliziert werden können.

In diesem Fall fehlen 100 Offsets in jedem Kanal für die Tabelle t1 in der neu heraufgestuften Primärdatenbank. Weitere Informationen zum Einfügen der fehlenden Daten finden Sie unter Aktive Kanäle für Snowpipe Streaming im neu heraufgestuften Quellkonto wieder öffnen.

Anforderungen

Für die Snowpipe Streaming-Replikation sind die folgenden Mindestversionen erforderlich:

  • Snowflake Ingest SDK Version 1.1.1 und höher

  • Bei Verwendung des Kafka-Konnektors: Kafka-Konnektor Version 1.9.3 und höher

Replikation und Stagingbereiche

Für Stagingobjekte gelten die folgenden Einschränkungen:

  • Snowflake unterstützt derzeit die Stagingbereichsreplikation als Teil der gruppenbasierten Replikation (Replikations- und Failover-Gruppen). Die Stagingbereichsreplikation wird für die Datenbankreplikation nicht unterstützt.

  • Sie können einen externen Stagingbereich replizieren. Die Dateien in einem externen Stagingbereich werden jedoch nicht repliziert.

  • Sie können einen internen Stagingbereich replizieren. Um die Dateien in einem internen Stagingbereich zu replizieren, müssen Sie in dem Stagingbereich eine Verzeichnistabelle aktivieren. Snowflake repliziert nur die Dateien, die durch die Verzeichnistabelle zugeordnet sind.

  • Wenn Sie einen internen Stagingbereich mit Verzeichnistabelle replizieren, können Sie die Verzeichnistabelle weder im primären noch im sekundären Stagingbereich deaktivieren. Die Verzeichnistabelle enthält wichtige Informationen zu den replizierten Dateien und zu Dateien, die mit einer COPY-Anweisung geladen wurden.

  • Eine Aktualisierungsoperation schlägt fehl, wenn die Verzeichnistabelle in einem internen Stagingbereich eine Datei enthält, die größer als 2 GB ist. Um diese Einschränkung zu umgehen, verschieben Sie alle Dateien, die größer als 5 GB sind, in einen anderen Stagingbereich.

    Sie können die Verzeichnistabelle eines primären oder sekundären Stagingbereichs oder eines Stagingbereichs, der zuvor repliziert wurde, nicht deaktivieren. Führen Sie diese Schritte aus, bevor Sie die Datenbank, die den Stagingbereich enthält, zu einer Replikations- oder Failover-Gruppe hinzufügen.

    1. Deaktivieren Sie die Verzeichnistabelle des primären Stagingbereichs.

    2. Verschieben Sie die Dateien, die größer als 5 GB sind, in einen anderen Stagingbereich, bei dem keine Verzeichnistabelle aktiviert ist.

    3. Nachdem Sie die Dateien in einen anderen Stagingbereich verschoben haben, aktivieren Sie die Verzeichnistabelle für den primären Stagingbereich wieder.

  • Dateien in Benutzer-Stagingbereichen und in Tabellen-Stagingbereichen werden nicht repliziert.

  • Bei benannten externen Stagingbereichen, die eine Speicherintegration verwenden, müssen Sie vor dem Failover die Vertrauensstellung für sekundäre Speicherintegrationen in Ihren Zielkonten konfigurieren. Weitere Informationen dazu finden Sie unter Cloudspeicherzugriff für sekundäre Speicherintegrationen konfigurieren.

  • Wenn Sie einen externen Stagingbereich mit Verzeichnistabelle replizieren und die automatische Aktualisierung für die primäre Verzeichnistabelle konfiguriert haben, müssen Sie vor dem Failover die automatische Aktualisierung für die sekundäre Verzeichnistabelle konfigurieren. Weitere Informationen dazu finden Sie unter Konfigurieren der automatischen Aktualisierung von Verzeichnistabellen in sekundären Stagingbereichen.

  • Ein Kopierbefehl kann länger dauern als erwartet, wenn die Verzeichnistabelle eines replizierten Stagingbereichs nicht mit den replizierten Dateien in dem Stagingbereich konsistent ist. Um die Konsistenz einer Verzeichnistabelle herzustellen, aktualisieren Sie diese mit einer ALTER STAGE … REFRESH-Anweisung. Um den Konsistenzstatus einer Verzeichnistabelle zu überprüfen, verwenden Sie die Funktion SYSTEM$GET_DIRECTORY_TABLE_STATUS.

Replikation und Pipes

Für Pipe-Objekte gelten die folgenden Einschränkungen:

  • Snowflake unterstützt derzeit die Pipe-Replikation als Teil der gruppenbasierten Replikation (Replikations- und Failover-Gruppen). Die Pipe-Replikation wird für die Datenbankreplikation nicht unterstützt.

  • Snowflake repliziert den Kopierverlauf einer Pipe nur dann, wenn die Pipe zur gleichen Replikationsgruppe gehört wie ihre Zieltabelle.

  • Die Replikation von Benachrichtigungsintegrationen wird nicht unterstützt.

  • Um Benachrichtigungen zu erhalten, müssen Sie vor dem Failover eine sekundäre Auto-Erfassungs-Pipe in einem Zielkonto konfigurieren. Weitere Informationen dazu finden Sie unter Konfigurieren von Benachrichtigungen für sekundäre Auto-Erfassungs-Pipes.

Replikation von gespeicherten Prozeduren und benutzerdefinierten Funktionen (UDFs)

Gespeicherte Prozeduren und UDFs werden von einer Primärdatenbank in Sekundärdatenbanken repliziert.

Gespeicherte Prozeduren und UDFs und Stagingbereiche

Wenn eine gespeicherte Prozedur oder UDF von Dateien in einem Stagingbereich abhängt (z. B. wenn die gespeicherte Prozedur in Python-Code definiert ist, der aus einem Stagingbereich hochgeladen wird), müssen Sie den Stagingbereich und die Dateien in die Sekundärdatenbank replizieren. Weitere Informationen zum Replizieren von Stagingbereichen finden Sie unter Replikation von Stagingbereichen, Pipes und des Ladeverlaufs.

Wenn beispielsweise eine Primärdatenbank über eine Python-Inline-UDF verfügt, die jeden Code importiert, der in einem Stagingbereich gespeichert ist, funktioniert die UDF erst, wenn auch der Stagingbereich und der importierte Code in die Sekundärdatenbank repliziert wurden.

Gespeicherte Prozeduren und UDFs und externer Netzwerkzugriff

Wenn eine gespeicherte Prozedur oder UDF vom Zugriff auf einen externen Netzwerkstandort abhängt, müssen Sie die folgenden Objekte replizieren:

  • EXTERNAL ACCESS INTEGRATIONS muss in der Liste allowed_integration_types der Replikations- oder Failover-Gruppe enthalten sein.

  • Die Datenbank, die die Netzwerkregel enthält.

  • Die Datenbank, die das Geheimnis enthält, in dem die Anmeldeinformationen für die Authentifizierung beim externen Netzwerkstandort gespeichert sind.

    Bemerkung

    Unterstützung der Geheimnisreplikation ist in Bundle 2023_08 (Standardmäßig aktiviert) verfügbar. Sie müssen das BCR-Bundle aktivieren, um Geheimnisobjekte zu replizieren, die die Anmeldeinformationen für die Authentifizierung bei den externen Netzwerkstandorten speichern, auf die die Integration des externen Zugriffs verweist.

  • Wenn das Geheimnisobjekt auf eine Sicherheitsintegration verweist, müssen Sie SECURITY INTEGRATIONS in die Liste allowed_integration_types der Replikations- oder Failover-Gruppe aufnehmen.

Replikation und Streams

In diesem Abschnitt werden empfohlene Vorgehensweisen und potenzielle Problembereiche bei der Replikation von Streams in Replizieren von Datenbanken über mehrere Konten oder Kontoreplikation und Failover/Failback beschrieben.

Unterstützte Quellobjekte für Streams

Replizierte Streams können erfolgreich die Änderungsdaten für Tabellen und Ansichten innerhalb derselben Datenbank verfolgen.

Derzeit werden die folgenden Quellobjekttypen nicht unterstützt:

  • Externe Tabellen

  • Tabellen oder Ansichten in Datenbanken, die von den Stream-Datenbanken getrennt sind, es sei denn, beide Datenbanken – die Stream-Datenbank und die Datenbank, die das Quellobjekt speichert – sind in derselben Replikations- oder Failover-Gruppe enthalten.

  • Tabellen oder Ansichten in freigegebenen Datenbanken (d. h. Datenbanken, die von Anbieterkonten für Ihr Konto freigegeben wurden)

Die Replikation von Streams auf Verzeichnistabellen wird unterstützt, wenn Sie Replikation von Stagingbereichen, Pipes und des Ladeverlaufs aktivieren.

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.

Vermeiden von Datenkopien

Bemerkung

Zusätzlich zu dem in diesem Abschnitt beschriebenen Szenario können Datenstreams in einer Sekundärdatenbank bei der erstmaligen Aktualisierungsoperation möglicherweise doppelte Zeilen zurückgeben. In diesem Fall bezieht sich doppelte Zeilen auf eine einzelne Zeile mit mehreren METADATA$ACTION-Spaltenwerten.

Nach der ersten Aktualisierungsoperation sollte dieses spezielle Problem von Sekundärdatenbanken nicht mehr auftreten.

Eine Datenduplizierung tritt auf, wenn DML-Operationen dieselben Änderungsdaten aus einem Stream mehrfach schreiben, ohne eine Eindeutigkeitsprüfung auszuführen. Dies kann vorkommen, wenn ein Stream und eine Zieltabelle für die Stream-Änderungsdaten in separaten Datenbanken gespeichert sind und diese Datenbanken nicht in dieselbe Replikations- oder Failover-Gruppe übertragen werden.

Angenommen, Sie fügen regelmäßig Änderungsdaten aus Stream s in Tabelle dt ein. (Für dieses Beispiel spielt das Quellobjekt für den Stream keine Rolle.) Stream- und Zieltabelle werden in getrennten Datenbanken gespeichert.

  1. Zum Zeitstempel t1 wird eine Zeile in die Quelltabelle von Stream s eingefügt und eine neue Tabellenversion erstellt. Der Stream speichert den Offset dieser Tabellenversion.

  2. Zum Zeitstempel t2 wird die Sekundärdatenbank, in der der Stream gespeichert ist, aktualisiert. Der replizierte Stream s speichert nun den Offset.

  3. Zum Zeitstempel t3 werden die Änderungsdaten von Stream s in die Tabelle dt eingefügt.

  4. Zum Zeitstempel t4 wird für die Sekundärdatenbank, die Stream s speichert, ein Failover ausgeführt.

  5. Zum Zeitstempel t5 werden die Änderungsdaten von Stream s erneut in die Tabelle dt eingefügt.

Um diese Situation zu vermeiden, müssen Sie Replikation und Failover für alle Datenbanken, in denen die Streams und deren Zieltabellen gespeichert sind, zusammen ausführen.

Streamreferenzen in WHEN-Klausel von Aufgaben

Um unerwartetes Verhalten zu vermeiden, wenn Sie replizierte Aufgaben ausführen, die Streams in der WHEN boolean_expr-Klausel referenzieren, gibt es folgende Optionen:

  • Erstellen Sie die Aufgaben und Streams in derselben Datenbank oder

  • Wenn Streams in einer anderen Datenbank gespeichert sind als die Aufgaben, die auf sie verweisen, schließen Sie beide Datenbanken in dieselbe Failover-Gruppe ein.

Wenn eine Aufgabe auf einen Stream in einer separaten Datenbank verweist und beide Datenbanken nicht in der gleichen Failover-Gruppe enthalten sind, könnte das Failover der Datenbank, die die Aufgabe enthält, ohne die Datenbank ausgeführt werden, die den Stream enthält. In diesem Szenario wird bei Fortsetzung der Aufgabe in der ausgefallenen Datenbank ein Fehler erfasst, wenn versucht wird, die Aufgabe auszuführen, und der referenzierte Stream nicht gefunden wird. Dieses Problem kann gelöst werden, indem entweder ein Failover der Datenbank ausgeführt wird, die den Stream enthält, oder Datenbank und Stream in demselben Konto wie die fehlgeschlagene Datenbank, die die Aufgabe enthält, neu erstellt werden.

Veralten von Streams

Wenn ein Stream in der Primärdatenbank veraltet, veraltet auch der replizierte Stream in einer Sekundärdatenbank, sodass dessen Daten nicht mehr abgefragt und Änderungsdaten nicht mehr verbraucht werden können. Um dieses Problem zu lösen, erstellen Sie den Stream in der Primärdatenbank neu (mit CREATE OR REPLACE STREAM). Wenn die Sekundärdatenbank aktualisiert wird, ist der replizierte Stream wieder lesbar.

Beachten Sie, dass der Offset für einen neu erstellten Stream standardmäßig die aktuelle Tabellenversion ist. Sie können einen Stream, der auf eine frühere Tabellenversion verweist, mit Time Travel neu erstellen. Der replizierte Stream wäre dann jedoch nicht lesbar. Weitere Informationen dazu finden Sie unter Streamreplikation und Time Travel (unter diesem Thema).

Streamreplikation und Time Travel

Wenn nach dem Failover einer Primärdatenbank ein Stream in der Datenbank Time Travel verwendet, um eine Tabellenversion für das Quellobjekt zu einem Zeitpunkt vor dem letzten Aktualisierungszeitstempel zu lesen, kann der replizierte Stream nicht abgefragt und Änderungsdaten können nicht verbraucht werden. Ebenso schlägt das Abfragen der Änderungsdaten für ein Quellobjekt zu einem Zeitpunkt vor dem letzten Aktualisierungszeitstempel bei Verwendung der CHANGES-Klausel in SELECT-Anweisungen mit einem Fehler fehl.

Dies liegt daran, dass bei einer Aktualisierungsoperation die Tabellenhistorie zu einer einzigen Tabellenversion zusammenfasst wird. Iterative Tabellenversionen, die vor dem Zeitstempel der Aktualisierungsoperation erstellt wurden, werden in der Tabellenhistorie der replizierten Quellobjekte nicht aufbewahrt.

Betrachten Sie das folgende Beispiel:

Stream replication and Time Travel
  1. Tabelle t1 wird in der Primärdatenbank erstellt und die Änderungsverfolgung aktiviert (Tabellenversion tv0). Durch nachfolgende DML-Transaktionen werden die Tabellenversionen tv1 und tv2 erstellt.

  2. Die Sekundärdatenbank, die die Tabelle t1 enthält, wird aktualisiert. Die Tabellenversion dieser replizierten Tabelle ist tv2, wobei die Tabellenhistorie jedoch nicht repliziert wird.

  3. In der Primärdatenbank wird ein Stream erstellt, dessen Offset mithilfe von Time Travel auf die Tabellenversion tv1 gesetzt wird.

  4. Für die Sekundärdatenbank wird ein Failover ausgeführt, wodurch sie zur Primärdatenbank wird.

  5. Das Abfragen von Stream s1 gibt einen Fehler zurück, da die Tabellenversion tv1 nicht in der Tabellenhistorie enthalten ist.

Beachten Sie Folgendes: Wenn durch eine nachfolgende DML-Transaktion auf Tabelle t1 die Tabellenversion auf tv3 iteriert wird, wird der Offset für Stream s1 vorverlegt. Der Stream ist wieder lesbar.

Vermeiden von Datenverlusten

Datenverlusten können auftreten, wenn die letzte Aktualisierungsoperation einer Sekundärdatenbank nicht vor der Failover-Operation abgeschlossen ist. Wir empfehlen, Ihre Sekundärdatenbanken regelmäßig zu aktualisieren, um dieses Risiko zu minimieren.

Replikation und Aufgaben

In diesem Abschnitt wird die Replikation von Aufgaben in Replizieren von Datenbanken über mehrere Konten oder Kontoreplikation und Failover/Failback beschrieben.

Replikationsszenarios

In der folgenden Tabelle sind die verschiedenen Aufgabenszenarios beschrieben, und es wird angegeben, ob die Aufgaben repliziert werden oder nicht. Wenn nicht anders angegeben, beziehen sich die Szenarios sowohl auf eigenständige Aufgaben als auch auf Aufgaben in einem DAG:

Szenario

Repliziert

Anmerkungen

Aufgabe wurde erstellt und entweder fortgesetzt oder manuell ausgeführt (mit EXECUTE TASK). Durch Fortsetzen oder Ausführen einer Aufgabe wird eine Erstversion der Aufgabe erstellt.

Aufgabe wurde erstellt, aber nie fortgesetzt oder ausgeführt.

Aufgabe wurde neu erstellt (mit CREATE OR REPLACE TASK), aber nie fortgesetzt oder ausgeführt.

Die letzte Version vor dem Neuerstellen der Aufgabe wurde repliziert.

Durch Fortsetzen oder manuelles Ausführen der Aufgabe wird eine neue Version festgeschrieben. Wenn die Datenbank erneut repliziert wird, wird die neue oder neueste Version in die Sekundärdatenbank repliziert.

Aufgabe wurde erstellt und fortgesetzt oder ausgeführt, anschließend geändert (mit ALTER TASK), aber nicht wieder fortgesetzt oder ausgeführt.

Durch Fortsetzen oder manuelles Ausführen einer Aufgabe wird eine neue Version festgeschrieben, die alle Änderungen an den Aufgabenparametern enthält. Da die neuen Änderungen nie mit Commit festgeschrieben wurden, wird die letzte Version vor dem Anhalten und Ändern der Aufgabe repliziert.

Beachten Sie: Wenn die geänderte Aufgabe nicht innerhalb einer Aufbewahrungsfrist (derzeit 30 Tage) fortgesetzt wird, wird die letzte Version der Aufgabe gelöscht. Nach diesem Zeitraum wird die Aufgabe nicht mehr in eine Sekundärdatenbank repliziert, es sei denn, sie wird erneut fortgesetzt.

Eigenständige Aufgabe wurde erstellt und fortgesetzt oder ausgeführt, dann aber gelöscht.

Stammaufgabe in einem DAG wurde erstellt und fortgesetzt oder ausgeführt, aber anschließend angehalten und gelöscht.

Der gesamte DAG wird nicht in eine Sekundärdatenbank repliziert.

Eine untergeordnete Aufgabe in einem DAG wird erstellt und fortgesetzt oder ausgeführt, aber anschließend angehalten und gelöscht.

Die letzte Version des DAG (bevor die Aufgabe angehalten und gelöscht wurde) wird in eine Sekundärdatenbank repliziert.

Status „Fortgesetzt“ oder „Angehalten“ von replizierten Aufgaben

Wenn jede der folgenden Bedingungen erfüllt ist, wird eine Aufgabe im Status „Fortgesetzt“ in die Sekundärdatenbank repliziert:

  • Eine eigenständige oder Stammaufgabe befindet sich in der Primärdatenbank im Status „Fortgesetzt“, wenn die Replikations- oder Aktualisierungsoperation beginnt und bis zum Abschluss der Operation. Befindet sich eine Aufgabe nur während eines Teils dieses Zeitraums im Status „Fortgesetzt“, kann sie dennoch im Status „Fortgesetzt“ repliziert werden.

    Eine untergeordnete Aufgabe befindet sich mit seiner neuesten Version im Status „Fortgesetzt“.

  • Die übergeordnete Datenbank wurde zusammen mit Rollenobjekten derselben oder einer anderen Replikations- oder Failover-Gruppe in das Zielkonto repliziert.

    Nachdem die Rollen und die Datenbank repliziert wurden, müssen Sie die Objekte im Zielkonto aktualisieren, indem Sie ALTER REPLICATION GROUP … REFRESH bzw. ALTER FAILOVER GROUP … REFRESH ausführen. Wenn Sie die Datenbank durch Ausführen von ALTER DATABASE … REFRESH aktualisieren, wird der Status der Aufgaben in der Datenbank in „Angehalten“ geändert.

    Eine Replikations- oder Aktualisierungsoperation umfasst auch Berechtigungszuweisungen für eine Aufgabe, die zum Zeitpunkt der Commit-Ausführung der neuesten Tabellenversion gültig waren. Weitere Informationen dazu finden Sie unter Replizierte Aufgaben und Berechtigungszuweisungen (unter diesem Thema).

Wenn diese Bedingungen nicht erfüllt sind, wird die Aufgabe im Status „Angehalten“ in eine Sekundärdatenbank repliziert.

Bemerkung

Alle sekundären Aufgaben werden angehalten, unabhängig von ihrem state-Wert. Weitere Informationen dazu finden Sie unter Aufgabenausführung nach einem Failover.

Replizierte Aufgaben und Berechtigungszuweisungen

Wenn die übergeordnete Datenbank zusammen mit Rollenobjekten derselben oder einer anderen Replikations- oder Failover-Gruppe in ein Zielkonto repliziert wird, werden auch die den Aufgaben in der Datenbank erteilten Berechtigungen repliziert.

Die folgende Logik bestimmt, welche Aufgabenberechtigungen bei einer Replikations- oder Aktualisierungsoperation repliziert werden:

  • Wenn der aktuelle Aufgabeneigentümer (d. h. die Rolle mit OWNERSHIP-Berechtigung für die Aufgabe) dieselbe Rolle ist wie bei der letzten Fortsetzung der Aufgabe, werden alle aktuell für die Aufgabe erteilten Berechtigungen in die Sekundärdatenbank repliziert.

  • Wenn der aktuelle Aufgabeneigentümer nicht dieselbe Rolle ist wie bei der letzten Fortsetzung der Aufgabe, dann wird in die Sekundärdatenbank nur die OWNERSHIP-Berechtigung repliziert, die der Eigentümerrolle in der Aufgabenversion zugewiesen wurde.

  • Wenn die aktuelle Rolle des Aufgabeneigentümers nicht verfügbar ist (z. B. wenn eine untergeordnete Aufgabe gelöscht wurde, aber eine neue Version des DAG noch nicht mit Commit bestätigt wurde), wird in die Sekundärdatenbank nur die OWNERSHIP-Berechtigung repliziert, die der Eigentümerrolle in der Aufgabenversion zugewiesen wurde.

Aufgabenausführung nach einem Failover

Nachdem eine sekundäre Failover-Gruppe zur primären Gruppe heraufgestuft wurde, werden alle fortgesetzten Aufgaben in Datenbanken innerhalb der Failover-Gruppe schrittweise geplant. Die Zeit, die zur Wiederherstellung der normalen Planung aller fortgesetzten eigenständigen Aufgaben und DAGs benötigt wird, hängt von der Anzahl der fortgesetzten Aufgaben in einer Datenbank ab.

Replikation und Tags

Tags und deren Zuweisungen können von einem Quellkonto in ein Zielkonto repliziert werden.

Tag-Zuweisungen können nach der ersten Replikation vom Quellkonto im Zielkonto nicht mehr geändert werden. So ist beispielsweise das Setzen eines Tags auf eine Sekundärdatenbank (d. h. eine replizierte Datenbank) nicht zulässig. Um Tag-Zuweisungen im Zielkonto zu ändern, ändern Sie diese im Quellkonto, und replizieren Sie sie dann in das Zielkonto.

Um Tags erfolgreich zu replizieren, müssen Sie sicherstellen, dass die Replikations- oder Failover-Gruppe Folgendes umfasst:

  • Die Datenbank, die die Tags in der Eigenschaft ALLOWED_DATABASES enthält.

  • Andere Objekte auf Kontoebene, die ein Tag in der Eigenschaft OBJECT_TYPES haben (z. B. ROLES, WAREHOUSES).

    Weitere Informationen dazu finden Sie unter CREATE REPLICATION GROUP und CREATE FAILOVER GROUP.

Historische Nutzungsdaten

Historische Nutzungsdaten für Aktivitäten in einer Primärdatenbank werden nicht in Sekundärdatenbanken repliziert. Jedes Konto verfügt über einen eigenen Abfrageverlauf, einen eigenen Anmeldeverlauf usw.

Historische Nutzungsdaten umfassen die Abfragedaten, die von den folgenden Snowflake Information Schema-Tabellenfunktionen oder Account Usage-Ansichten zurückgegeben werden:

  • COPY_HISTORY

  • LOGIN_HISTORY

  • QUERY_HISTORY

  • usw.