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 Verwaiste Referenzen (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 externe Tabellen

Externe Tabellen in der primären Datenbank 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 diese Einschränkung zu umgehen, empfehlen wir Ihnen, die externen Tabellen in eine separate Datenbank zu verschieben, 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äre Datenbank im Zielkonto zur primären Datenbank heraufgestuft haben, müssten Sie die externen Tabellen in der Datenbank neu erstellen.

Replikation und Richtlinien (Maskierung und Zeilenzugriff)

Wenn bei Richtlinien für Maskierung und Zeilenzugriff 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 Richtlinie, aber mindestens eines der zur Replikation genehmigten Konten befindet sich in einer niedrigeren Edition.

  • Eine in der Primärdatenbank enthaltene Richtlinie hat einen Verweis auf eine Richtlinie in einer anderen Datenbank.

Replikation und Tabellenstreams

Wie in Replizierte Datenbankobjekte angegeben, werden Tabellenstreams in einer primären Datenbank derzeit nicht in sekundäre Datenbanken repliziert.

Wenn außerdem die Änderungsverfolgung in einer Tabelle aktiviert ist, werden die Änderungsverfolgungsdatensätze in den Metadatenspalten nicht in sekundäre Datenbanken repliziert. Um Änderungsdaten in Tabellen in einer sekundären Datenbank zu verfolgen, ist es derzeit erforderlich, die sekundäre Datenbank zur primären Datenbank hochzustufen. Dann können Benutzer Tabellenstreams in der gleichen Datenbank oder einer anderen Datenbank im gleichen Konto erstellen. Diese Tabellenstreams verfolgen nur Änderungen in den Tabellen, die nach dem Heraufstufen der sekundären Datenbank initiiert und abgeschlossen wurden.

Um einen Stream zu dem Zeitpunkt zu erstellen, an dem die Datenbank, die eine Tabelle speichert, heraufgestuft wurde, verwenden Sie die Syntax CREATE STREAM … AT | BEFORE. Die AT | BEFORE-Klausel bestimmt den Zeitpunkt in der Vergangenheit, ab dem historische Daten für die Tabelle angefordert werden:

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.

Verwaiste Referenzen

Verweise auf Objekte in einer anderen Datenbank

Analysieren Sie sorgfältig, ob Ansichten oder Tabelleneinschränkungen einer Primärdatenbank auf Objekte einer anderen 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 mit folgender Fehlermeldung fehlschlägt:

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

    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.

    Um diese Einschränkung zu umgehen, empfehlen wir Ihnen, materialisierte Ansichten und die Objekte, auf die sie verweisen, in derselben Datenbank zu speichern.

Einschränkungen

Derzeit führen verwaiste Fremdschlüssel zum Fehlschlagen der Replikation mit folgender Fehlermeldung:

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

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.

Um diese Einschränkung zu umgehen, empfehlen wir Ihnen, verknüpfte Tabellen in der gleichen Datenbank zu speichern.

Verweise auf gelöschte Objekte

Das Löschen eines Objekts, das von einem anderen Objekt in derselben oder einer anderen Datenbank referenziert wird, führt zu einer verwaisten Referenz. Wenn ein Objekt in der Primärdatenbank auf ein gelöschtes Objekt verweist, schlägt ein Replikationsvorgang mit folgender Fehlermeldung fehl:

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

Um diese Einschränkung zu umgehen, empfehlen wir Ihnen, eine der folgenden Aktionen auszuführen:

  • Löschen Sie alle referenzierten Objekte.

  • Modifizieren Sie die verweisenden Objekte (z. B. modifizieren Sie eine materialisierte Ansicht mit ALTER MATERIALIZED VIEW). Verweisen Sie entweder auf ein anderes Objekt, oder entfernen Sie den Verweis auf das gelöschte Objekt.

  • Löschen Sie alle Objekte in der primären Datenbank, die auf gelöschte Objekte verweisen.

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.