Hinweise zur Datenbankreplikation

Unter diesem Thema wird das Verhalten bestimmter Snowflake-Features in sekundären Datenbanken beschrieben, und es werden allgemeine Anleitungen zur Verwendung replizierter Objekte und Date bereitgestellt.

Unter diesem Thema:

Dieser Abschnitt beschreibt das Verhalten bestimmter Snowflake-Funktionen in sekundären Datenbanken und bietet allgemeine Anleitungen zur Verwendung replizierter Objekte und Daten.

Replikation und Automatic Clustering

In der Primärdatenbank überwacht Snowflake gruppierte 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 materialisierte Ansichten

In der 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 Hintergrundservice aktualisiert, der von Snowflake bereitgestellte Computeressource nutzt. Wenn das Automatic Clustering für eine materialisierte Ansicht aktiviert ist, wird die Ansicht außerdem überwacht und bei Bedarf in der Primärdatenbank erneut geclustert.

Durch eine Aktualisierungsoperation werden die Definitionen der materialisierten Ansichten in eine sekundäre Datenbank repliziert. Die Daten der materialisierten Ansichten werden jedoch nicht repliziert. Dies bedeutet, dass einige oder alle Daten in den materialisierten Ansichten veraltet sein können.

Wenn Sie die automatische Hintergrundwartung von materialisierten Ansichten in einer sekundären Datenbank durchführen möchten, legen Sie explizit AUTO_REFRESH_MATERIALIZED_VIEWS_ON_SECONDARY = TRUE fest, entweder wenn Sie die sekundäre Datenbank erstellen (mit CREATE DATABASE … AS REPLICA OF) oder später (mit ALTER DATABASE). Wenn für eine materialisierte Ansicht in der Primärdatenbank das Automatic Clustering aktiviert ist, können Sie durch Festlegen von AUTO_REFRESH_MATERIALIZED_VIEWS_ON_SECONDARY = TRUE für eine Sekundärdatenbank auch deren materialisierte Ansicht automatisch überwachen und das Reclustering durchführen.

Siehe auch Verweise auf Objekte in einer anderen Datenbank (unter diesem Thema).

Bemerkung

Wenn bei einer sekundären Datenbank der Parameter AUTO_REFRESH_MATERIALIZED_VIEWS_ON_SECONDARY aktiviert ist, werden dem Konto Gebühren für die Wartung der materialisierten Ansicht in Rechnung gestellt.

Replikation und Maskierungsrichtlinien

Wenn eine der folgenden Bedingungen erfüllt ist, schlägt die erste Replikationsoperation oder eine nachfolgende Aktualisierungsoperation fehl:

  • Die Primärdatenbank befindet sich in einem Enterprise-Konto (oder höher) und enthält eine Maskierungsrichtlinie, aber eines oder mehrere der zur Replikation genehmigten Konten befinden sich in niedrigeren Editionen.

  • Eine in der Primärdatenbank enthaltene Maskierungsrichtlinie wird auf Spalten einer Tabelle oder Ansicht in einer anderen Datenbank angewendet oder umgekehrt.

Time Travel

Das Abfragen von Tabellen und Ansichten in einer sekundären Datenbank mithilfe von Time Travel kann andere Ergebnisse liefern als das Ausführen derselben Abfrage in der primären Datenbank.

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ären Datenbank beginnt, wenn die sekundäre Datenbank mit den in Tabellen der primären Datenbank geschriebenen DML-Operationen (d. h. Ändern oder Löschen von Daten) aktualisiert wird.

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 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.

Verweise auf Objekte in einer anderen Datenbank

Analysieren Sie sorgfältig, ob Ansichten oder Tabelleneinschränkungen in einer Primärdatenbank auf eine andere Datenbank verweisen.

Ansichten
  • Nicht materialisierte Ansichten, die auf ein Objekt in einer anderen Datenbank verweisen (z. B. Tabellenspalten, andere Ansichten, UDFs oder Stagingbereiche), können repliziert werden, da diese Art von Referenz auf Namen basiert. Namensbasierte Verweise führen nicht zum Fehlschlagen der Replikation. Abfragen auf Ansichten sekundärer Datenbanken schlagen jedoch fehl, wenn die anderen Datenbanken nicht in derselben Region repliziert werden.

    Angenommen, die Ansicht v1 in der Datenbank d1 verweist auf die Tabellen t1 und t2 in den Datenbanken d1 bzw. d2. Um die Ansicht V1 der Sekundärdatenbank d1 erfolgreich abzufragen, muss auch die Sekundärdatenbank d2 im Konto vorhanden sein (z. B. als eine weitere Sekundärdatenbank). Außerdem müssen für konsistente Abfrageergebnisse auf den Primärdatenbanken die Sekundärdatenbanken d1 und d2 gleichzeitig aktualisiert werden.

  • Materialisierte Ansichten, die auf ein Objekt in einer anderen Datenbank verweisen, führen derzeit dazu, dass die Replikations- oder Aktualisierungsoperation fehlschlägt. Dies liegt daran, dass materialisierte Ansichten Objekte eher nach ID als nach Namen referenzieren. Ein Datenbank-Snapshot kann keine ID-basierten Verweise auf Objekte außerhalb der Datenbank auflösen.

Einschränkungen

Derzeit führen verwaiste Fremdschlüssel zum Fehlschlagen der Replikation. Diese Situation tritt auf, wenn ein Fremdschlüssel in der Primärdatenbank auf einen Primärschlüssel in einer anderen Datenbank verweist oder umgekehrt. Dies liegt daran, dass Verweise auf Nebenbedingungen ID-basiert sind. Ein Datenbank-Snapshot kann keine ID-basierten Verweise auf Objekte außerhalb der Datenbank auflösen.

Um die Fremdschlüsselreferenzen in Ihrem Konto anzuzeigen, fragen Sie die Ansicht TABLE_CONSTRAINTS im Information Schema oder im Schema ACCOUNT_USAGE ab.

Replikation und Zugriffssteuerung

Sekundäre Datenbanken sind schreibgeschützt. Der Datenbankeigentümer (d. h. die Rolle, die die Berechtigung OWNERSHIP für die sekundäre Datenbank besitzt) kann jedoch mithilfe von GRANT <Berechtigungen> … TO ROLE anderen Rollen Berechtigungen für Datenbankobjekte (d. h. Schemas, Tabellen, Ansichten usw.) erteilen.

Historische Nutzungsdaten

Historische Nutzungsdaten für Aktivitäten in der 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 Information Schema-Tabellenfunktionen oder Account Usage-Ansichten zurückgegeben werden:

  • COPY_HISTORY

  • LOGIN_HISTORY

  • QUERY_HISTORY

  • usw.