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.
Spezifische Hinweise zur Datenbankreplikation finden Sie unter Hinweise 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.
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ären Datenbank 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:
|
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. |
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.
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])
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 dem Konto eine Netzwerkrichtlinie zugeordnet ist, nehmen Sie
NETWORK POLICIES
undACCOUNT PARAMETERS
in die ListeOBJECT_TYPES
auf.Wenn eine Netzwerkrichtlinie einem Benutzer zugeordnet ist, fügen Sie
USERS
in die ListeOBJECT_TYPES
ein.
Weitere Informationen dazu finden Sie unter Netzwerkrichtlinien unter dem Thema Replikation von Sicherheitsintegrationen und Netzwerkrichtlinien über mehrere Konten hinweg.
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 keinen globalen Bezeichner. Wenn ein Zielkonto vom Quellkonto aus aktualisiert wird, führt die Aktualisierungsoperation zum Löschen aller Kontoobjekte der Typen in der OBJECT_TYPES
-Liste (z. B. USERS
oder ROLES
) des Zielkontos, die keinen globalen Bezeichner haben.
Informationen dazu, wie Sie das Löschen dieser Objekte verhindern können, finden Sie unter Schritt 5: Globale IDs auf Objekte anwenden, die von Skripten in Zielkonten erstellt wurden – Optional.
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 Sicherheitsrichtlinien.
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 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 hoher Änderungsrate¶
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
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.
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 von gespeicherten Prozeduren und benutzerdefinierten Funktionen (UDFs)¶
Gespeicherte Prozeduren und UDFs werden von einer Primärdatenbank in Sekundärdatenbanken repliziert.
Beachten Sie, dass die Replikation von Stagingbereichen noch nicht unterstützt wird. 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 manuell in die Sekundärdatenbank replizieren.
Wenn beispielsweise eine Primärdatenbank über eine Python-Inline-UDF verfügt, die jeden Code importiert, der in einem Stagingbereich gespeichert ist, wird die UDF in eine Sekundärdatenbank repliziert, funktioniert aber erst, wenn auch der Stagingbereich und der importierte Code manuell in die Sekundärdatenbank repliziert wurden.
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:
Verzeichnistabellen
Externe Tabellen
Tabellen oder Ansichten in Datenbanken, die von den Stream-Datenbanken getrennt sind.
Beachten Sie, dass dieses Design nur funktioniert, wenn sowohl die Stream-Datenbank als auch die Datenbank, die das Quellobjekt speichert, in derselben Replikations- oder Failover-Gruppe enthalten sind.
Tabellen oder Ansichten in freigegebenen Datenbanken (d. h. Datenbanken, die von Anbieterkonten für Ihr Konto freigegeben wurden)
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.
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.
Zum Zeitstempel
t1
wird eine Zeile in die Quelltabelle von Streams
eingefügt und eine neue Tabellenversion erstellt. Der Stream speichert den Offset dieser Tabellenversion.Zum Zeitstempel
t2
wird die Sekundärdatenbank, in der der Stream gespeichert ist, aktualisiert. Der replizierte Streams
speichert nun den Offset.Zum Zeitstempel
t3
werden die Änderungsdaten von Streams
in die Tabelledt
eingefügt.Zum Zeitstempel
t4
wird für die Sekundärdatenbank, die Streams
speichert, ein Failover ausgeführt.Zum Zeitstempel
t5
werden die Änderungsdaten von Streams
erneut in die Tabelledt
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:
Tabelle
t1
wird in der Primärdatenbank erstellt und die Änderungsverfolgung aktiviert (Tabellenversiontv0
). Durch nachfolgende DML-Transaktionen werden die Tabellenversionentv1
undtv2
erstellt.Die Sekundärdatenbank, die die Tabelle
t1
enthält, wird aktualisiert. Die Tabellenversion dieser replizierten Tabelle isttv2
, wobei die Tabellenhistorie jedoch nicht repliziert wird.In der Primärdatenbank wird ein Stream erstellt, dessen Offset mithilfe von Time Travel auf die Tabellenversion
tv1
gesetzt wird.Für die Sekundärdatenbank wird ein Failover ausgeführt, wodurch sie zur Primärdatenbank wird.
Das Abfragen von Stream
s1
gibt einen Fehler zurück, da die Tabellenversiontv1
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.
Streamreplikation aktivieren¶
Informationen zum Aktivieren der Vorschau für die Streamreplikation finden Sie unter Vorschau für das Aktivieren der Stream- und Aufgabenreplikation – Optional.
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.
Aufgabenreplikation aktivieren¶
Informationen zum Aktivieren der Vorschau für die Aufgabenreplikation finden Sie unter Vorschau für das Aktivieren der Stream- und Aufgabenreplikation – Optional.
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.
Löschen einer sekundären Replikations- oder Failover-Gruppe¶
Sie können eine sekundäre Replikations- oder Failover-Gruppe mit den Befehlen DROP REPLICATION GROUP bzw. DROP FAILOVER GROUP löschen. Nur der Eigentümer der Replikations- oder Failover-Gruppe (d. h. die Rolle mit OWNERSHIP-Berechtigung für die Gruppe) kann die Gruppe löschen.
Löschen einer primären Replikations- oder Failover-Gruppe¶
Eine primäre Replikations- oder Failover-Gruppe kann erst gelöscht werden, nachdem alle Replikate der Gruppe (d. h. alle sekundären Replikations- oder Failover-Gruppen) gelöscht wurden. Alternativ können Sie eine sekundäre Replikations- oder Failover-Gruppe zur primären Gruppe heraufstufen und dann die bisherige primäre Replikations- oder Failover-Gruppe löschen.
Beachten Sie, dass die Gruppe nur vom Eigentümer der Gruppe gelöscht werden kann.