Replikation von Stagingbereichen, Pipes und des Ladeverlaufs

Unter diesem Thema finden Sie Informationen zur Replikationsunterstützung für Datenpipeline-Objekte und zugehörige Metadaten, einschließlich Stagingbereichen, Speicherintegrationen, Pipes und den Ladeverlauf. Sie können diese Objekte replizieren, um das Failover für Erfassungs- und ETL-Pipelines über Regionen und Cloudplattformen hinweg zu konfigurieren.

Bevor Sie beginnen, empfehlen wir Ihnen, sich mit der Snowflake-Unterstützung für Replikation und Failover/Failback vertraut zu machen. Weitere Informationen dazu finden Sie unter Einführung in Replikation und Failover über mehrere Konten.

Anforderungen

Wichtig

Wenn eine Datenbank in einem Zielkonto, das Sie verwenden möchten, bereits Stagingbereiche und Pipes enthält, empfehlen wir Ihnen, den Support zu kontaktieren, bevor Sie die Replikation aktivieren. Wenn diese Datenbank in eine Replikations- oder Failover-Gruppe in Ihrem Quellkonto hinzugefügt wird, werden alle bereits vorhandenen Stagingbereiche und Pipes in der Datenbank gelöscht.

Bevor Sie Datenpipeline-Objekte replizieren können, müssen Sie die ETL-Replikation aktivieren. Die Unterstützung der ETL-Replikation ist Bestandteil von BCR-Bundle 2024_01. Sie können BCR-Bundle 2024_01 aktivieren, indem Sie die folgende Anweisung ausführen:

SELECT SYSTEM$ENABLE_BEHAVIOR_CHANGE_BUNDLE('2024_01');
Copy

Um beliebige externe Stagingbereiche replizieren zu können, die eine Speicherintegration verwenden, müssen Sie Ihre Replikations-/Failover-Gruppe auch für die Replikation von STORAGE INTEGRATIONS konfigurieren. Andernfalls werden die externen Stagingbereiche ohne die zugeordnete Speicherintegration repliziert.

Sie können eine ALTER REPLICATION GROUP- oder ALTER FAILOVER GROUP-Anweisung verwenden, um diese Eigenschaften für eine bestehende Gruppe zu ändern.

Bemerkung

Wenn Sie der Liste OBJECT_TYPES in Ihrer ALTER-Anweisung die Option INTEGRATIONS hinzufügen, müssen Sie auch alle anderen vorhandenen Objekte in die Liste aufnehmen, um zu vermeiden, dass diese Objekte im Zielkonto gelöscht werden. Dasselbe gilt, wenn Sie STORAGE INTEGRATIONS zur Liste ALLOWED_INTEGRATION_TYPES hinzufügen.

Beispiel:

ALTER FAILOVER GROUP my_failover_group SET
  OBJECT_TYPES = ROLES, INTEGRATIONS
  ALLOWED_INTEGRATION_TYPES = API INTEGRATIONS, STORAGE INTEGRATIONS;
Copy

Replikation und Stagingbereiche

In diesem Abschnitt wird der aktuelle Stand der Replikationsfunktionalität beschrieben, die Snowflake für verschiedene Typen von Stagingbereichen unterstützt.

Replikation von internen Stagingbereichen

In der folgenden Tabelle wird beschrieben, wie die Replikation für die einzelnen Typen von internen Stagingbereichen funktioniert.

Typ

Beschreibung der Replikationsunterstützung

Tabellen-Stagingbereich

Leere Tabellen-Stagingbereiche werden für Tabellen einer replizierten Datenbank erstellt. Dateien in Tabellen-Stagingbereichen werden nicht repliziert.

Benutzer-Stagingbereich

Für die Replikation von Benutzern und Benutzer-Stagingbereichen ist Business Critical Edition (oder höher) erforderlich.

Für replizierte Benutzer werden leere Benutzer-Stagingbereiche erstellt. Dateien in Benutzer-Stagingbereichen werden nicht repliziert.

Benannter Stagingbereich

Benannte interne Stagingbereiche werden repliziert, wenn Sie eine Datenbank replizieren.

Der Stagingbereich muss über eine aktivierte Verzeichnistabelle verfügen, damit die Dateien im Stagingbereich repliziert werden können.

Replikation von externen Stagingbereichen

Bemerkung

Snowflake repliziert keine Dateien in einem externen Stagingbereich. Die Cloudspeicher-URL verweist bei externen Stagingbereichen in Primär- und Sekundärdatenbanken auf denselben Speicherort.

In der folgenden Tabelle wird beschrieben, wie die Replikation für die einzelnen Arten von externen Stagingbereiche funktioniert.

Typ

Beschreibung der Replikationsunterstützung

Benannter Stagingbereich ohne Anmeldeinformationen (öffentlicher Speicherort)

Benannte externe Stagingbereiche werden repliziert, wenn Sie eine Datenbank replizieren. Die Dateien in einem externen Stagingbereich werden nicht repliziert.

Benannter Stagingbereich mit Anmeldeinformationen (privater Speicherort)

Replizierte Stagingbereiche enthalten auch die Anmeldeinformationen des Cloudanbieters wie geheime Schlüssel oder Zugriffstoken.

Benannter Stagingbereich mit Speicherintegration (privater Speicherort)

Für die Replikation von Speicherintegrationen ist die Business Critical Edition (oder höher) erforderlich.

In der Liste ALLOWED_INTEGRATION_TYPES der Replikations- oder Failover-Gruppe muss die Option STORAGE INTEGRATIONS enthalten sein: Weitere Informationen dazu finden Sie unter CREATE FAILOVER GROUP.

Außerdem ist es erforderlich, dass Sie die Vertrauensstellungen für Ihren Cloudspeicher in den Zielkonten konfigurieren. Weitere Informationen dazu finden Sie unter Cloudspeicherzugriff für sekundäre Speicherintegrationen konfigurieren.

Bemerkung

Wenn Sie einen sekundären Stagingbereich oder eine sekundäre Pipe einem anderen Cloudspeicherort zuordnen möchten als dem, der dem primären Objekt zugeordnet ist, wenden Sie sich an das Support-Team. Sie könnten zum Beispiel einen Speicherort in einer anderen Region wählen.

Hinweise

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

In diesem Abschnitt wird beschrieben, welche Replikationsfunktionen derzeit für die verschiedenen Typen von Pipes unterstützt werden.

Snowflake unterstützt die Replikation von folgenden Elementen:

  • Pipe-Objekte, einschließlich Pipes für die automatische Datenerfassung und für REST-Endpunkte, die Daten von externen Stagingbereichen laden

  • Parameter auf Pipe-Ebene

  • Berechtigungen für Pipe-Objekte

Bemerkung

Wenn Sie einen sekundären Stagingbereich oder eine sekundäre Pipe einem anderen Cloudspeicherort zuordnen möchten als dem, der dem primären Objekt zugeordnet ist, wenden Sie sich an das Support-Team. Sie könnten zum Beispiel einen Speicherort in einer anderen Region wählen.

Pipes in Sekundärdatenbanken

Pipes in einer Sekundärdatenbank erhalten zwar Benachrichtigungen, laden Daten aber erst, wenn Sie die Sekundärdatenbank zur Primärdatenbank heraufgestuft haben. Nach dem Heraufstufen einer Sekundärdatenbank beginnen die Pipes, alle Daten zu laden, die seit dem letzten Aktualisierungszeitpunkt (d. h. dem letzten Mal, als die ehemalige Primärdatenbank aktualisiert wurde) verfügbar sind.

Replikation von Pipes zur automatischen Datenerfassung

Im Falle eines Failover wird eine replizierte Auto-Erfassungs-Pipe zur neuen primären Pipe und kann Folgendes tun:

  • Laden aller Daten, die noch nicht geladen wurden. Dies schließt alle Daten ein, die seit der letzten Aktualisierung der neu heraufgestuften Primärdatenbank neu hinzugekommen sind.

  • Weiterhin Benachrichtigungen empfangen, wenn der Stagingbereich neue zu ladende Dateien enthält, und Daten aus diesen Dateien laden.

    Bemerkung

    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 Pipes für REST-Endpunkte

Bei Pipes, die die Snowpipe REST-API zum Laden von Daten verwenden, repliziert Snowflake die Pipes und deren Metadaten zum Ladeverlauf auf jedes von Ihnen angegebene Zielkonto. Bei den Zielkonten sind keine zusätzlichen Konfigurationsschritte erforderlich. Eine ausführliche Liste der Metadaten zum Ladeverlauf finden Sie unter Metadaten laden.

Um das Laden von Daten im Falle eines Failover fortzusetzen, rufen Sie von dem neu heraufgestuften Quellkonto aus die REST-API auf.

Hinweise

Bemerkung

Ein bekanntes Problem in der Vorschauversion dieses Features führt zu einem doppelten Laden von Dateien, die älter als 64 Tage sind. Als Problemumgehung sollten Sie nach der Replikation einer Tabelle 24 Stunden warten, bevor Sie ein Failover durchführen.

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.

Beispiel 1: Replizieren eines benannten internen Stagingbereichs

In diesem Beispiel wird gezeigt, wie die Replikation für interne Stagingbereiche funktioniert. Das Beispiel zeigt insbesondere, wie die Verzeichnistabelle die einzige Quelle der Wahrheit für Tabellenmetadaten vor und nach der Replikation ist.

Im ersten Teil des Beispiels werden die folgenden Aufgaben in einem Quellkonto erledigt.

  1. Erstellen Sie einen internen Stagingbereich mit dem Namen my_int_stage mit einer aktivierten Verzeichnistabelle, um die im Stagingbereich befindlichen Dateien zu replizieren. Kopieren Sie dann Daten aus einer Tabelle namens my_table in Dateien im Stagingbereich.

    Bemerkung

    Im Beispiel wird die Verzeichnistabelle nach dem Laden von file1 und file2 in den Stagingbereich aktualisiert, um die Tabellenmetadaten mit dem neuesten Satz von Dateien in der Stagingbereichsdefinition für die Verzeichnistabellen zu synchronisieren. Nach dem Laden von file3 findet jedoch keine Aktualisierungsoperation statt.

    CREATE OR REPLACE STAGE my_stage
      DIRECTORY = (ENABLE = TRUE);
    
    COPY INTO @my_stage/folder1/file1 from my_table;
    COPY INTO @my_stage/folder2/file2 from my_table;
    ALTER STAGE my_stage REFRESH;
    
    COPY INTO @my_stage/folder3/file3 from my_table;
    
    Copy
  2. Failover-Gruppe erstellen:

    CREATE FAILOVER GROUP my_stage_failover_group
      OBJECT_TYPES = DATABASES
      ALLOWED_DATABASES = my_database_1
      ALLOWED_ACCOUNTS = myorg.my_account_2;
    
    Copy

Im zweiten Teil des Beispiels wird der Replikations- und Failover-Prozess in einem Zielkonto vervollständigt:

  1. Erstellen Sie eine Failover-Gruppe als Replikat der Failover-Gruppe im Quellkonto, aktualisieren Sie die Objekte in der neuen Failover-Gruppe, und stufen Sie das Zielkonto zum Quellkonto herauf.

    CREATE FAILOVER GROUP my_stage_failover_group
      AS REPLICA OF myorg.my_account_1.my_stage_failover_group;
    
    ALTER FAILOVER GROUP my_stage_failover_group REFRESH;
    
    ALTER FAILOVER GROUP my_stage_failover_group PRIMARY;
    
    Copy
  2. Als Nächstes aktualisieren Sie die Verzeichnistabelle des replizierten Stagingbereichs und kopieren alle Dateien, die von der Verzeichnistabelle in my_stage verfolgt werden, in eine Tabelle namens my_table.

    Bemerkung

    Mit der COPY INTO-Anweisung werden file1 und file2 in die Tabelle geladen, aber nicht file3. Das liegt daran, dass die Verzeichnistabelle nach dem Hinzufügen von file3 im Quellkonto nicht aktualisiert wurde.

    ALTER STAGE my_stage REFRESH;
    
    COPY INTO my_table FROM @my_stage;
    
    Copy

Beispiel 2: Replizieren eines externen Stagingbereichs und einer Speicherintegration

Dieses Beispiel zeigt einen Beispiel-Workflow für das Replizieren eines externen Stagingbereichs und der Speicherintegration in ein Zielkonto.

Das Beispiel geht davon aus, dass Sie die folgenden Schritte bereits durchgeführt haben: Konfigurieren des sicheren Zugriffs auf Ihren Amazon S3-Bucket.

Im ersten Teil des Beispiels werden die folgenden Aufgaben in einem Quellkonto erledigt.

  1. Erstellen Sie eine Speicherintegration für einen Amazon S3-Bucket in Datenbank my_database_2.

    CREATE STORAGE INTEGRATION my_storage_int
      TYPE = external_stage
      STORAGE_PROVIDER = 's3'
      STORAGE_ALLOWED_LOCATIONS = ('s3://mybucket/path')
      STORAGE_BLOCKED_LOCATIONS = ('s3://mybucket/blockedpath')
      ENABLED = true;
    
    Copy
  2. Erstellen Sie einen externen Stagingbereich in der Datenbank my_database_2 unter Verwendung der Speicherintegration my_storage_int.

    CREATE STAGE my_ext_stage
      URL = 's3://mybucket/path'
      STORAGE_INTEGRATION = my_storage_int
    
    Copy
  3. Erstellen Sie eine Failover-Gruppe, und schließen Sie dabei Datenbank my_database_2 und Speicherintegrationsobjekte ein.

    CREATE FAILOVER GROUP my_external_stage_fg
      OBJECT_TYPES = databases, integrations
      ALLOWED_INTEGRATION_TYPES = storage integrations
      ALLOWED_DATABASES = my_database_2
      ALLOWED_ACCOUNTS = myorg.my_account_2;
    
    Copy

Im zweiten Teil des Beispiels wird der Replikations- und Failover-Prozess in einem Zielkonto vervollständigt:

  1. Erstellen Sie eine Failover-Gruppe als Replikat der Failover-Gruppe im Quellkonto, und führen Sie die Aktualisierungsoperation (Refresh) aus:

    CREATE FAILOVER GROUP my_external_stage_fg
      AS REPLICA OF myorg.my_account_1.my_external_stage_fg;
    
    ALTER FAILOVER GROUP my_external_stage_fg REFRESH;
    
    Copy
  2. Nachdem Sie die Speicherintegration in das Zielkonto repliziert haben, müssen Sie weitere Schritte ausführen, um die Berechtigungen Ihres Cloudanbieters zu aktualisieren, damit die Replikationsintegration Zugriff auf Ihren Cloudspeicher erhält. Weitere Informationen dazu finden Sie unter Cloudspeicherzugriff für sekundäre Speicherintegrationen konfigurieren.

Beispiel 3: Replizieren einer Auto-Erfassungs-Pipe

Dieses Beispiel bietet einen Beispielworkflow für die Replikation einer Pipe, die ein Amazon Simple Notification Service (SNS)-Thema mit Amazon Simple Queue Service (SQS) zum Automatisieren von Snowpipe verwendet.

Im Beispiel wird davon ausgegangen, dass Sie die folgenden Aufgaben bereits erledigt haben:

Beginnen Sie mit den folgenden Aufgaben in einem Quellkonto.

  1. Verwenden Sie den Befehl CREATE PIPE, um eine Pipe mit aktivierter automatischer Erfassung zu erstellen, die Daten aus dem externen Stagingbereich in eine Tabelle mit dem Namen mytable lädt.

    CREATE PIPE snowpipe_db.public.mypipe AUTO_INGEST=TRUE
     AWS_SNS_TOPIC='<topic_arn>'
     AS
       COPY INTO snowpipe_db.public.mytable
       FROM @snowpipe_db.public.my_s3_stage
       FILE_FORMAT = (TYPE = 'JSON');
    
    Copy
  2. Aktualisieren Sie die Pipe mit einer ALTER PIPE-Anweisung, um Daten der letzten 7 Tage aus dem Stagingbereich zu laden.

    ALTER PIPE mypipe REFRESH;
    
    Copy
  3. Verwenden Sie schließlich CREATE FAILOVER GROUP, um eine Failover-Gruppe zu erstellen, die die Replikation von Speicherintegrationen ermöglicht.

    CREATE FAILOVER GROUP my_pipe_failover_group
      OBJECT_TYPES = DATABASES, INTEGRATIONS
      ALLOWED_INTEGRATION_TYPES = STORAGE INTEGRATIONS
      ALLOWED_DATABASES = snowpipe_db
      ALLOWED_ACCOUNTS = myorg.my_account_2;
    
    Copy

Im zweiten Teil des Beispiels wird der Replikations- und Failover-Prozess in einem Zielkonto vervollständigt:

  1. Erstellen Sie eine Failover-Gruppe als Replikat der Failover-Gruppe im Quellkonto:

    CREATE FAILOVER GROUP my_pipe_failover_group
      AS REPLICA OF myorg.my_account_1.my_pipe_failover_group;
    
    Copy
  2. Führen Sie eine DESCRIBE INTEGRATION-Anweisung aus, um den ARN des AWS-IAM-Benutzers für Ihr Snowflake-Konto in der sekundären Bereitstellung abzurufen.

    Verwenden Sie den ARN, um dem IAM-Benutzer Zugriffsrechte auf Ihren S3 Bucket zu gewähren. Siehe Schritt 5: IAM-Benutzerberechtigungen für den Zugriff auf Bucket-Objekte erteilen.

    DESC INTEGRATION my_s3_storage_int;
    
    Copy
  3. Rufen Sie die Systemfunktion SYSTEM$GET_AWS_SNS_IAM_POLICY auf, um eine IAM-Richtlinie zu erstellen, die der neuen SQS-Warteschlange die Berechtigung erteilt, Ihr SNS-Thema zu abonnieren. Snowflake erstellt die neue SQS-Warteschlange in Ihrem Zielkonto, wenn Sie die Failover-Gruppe von Ihrem Quellkonto replizieren.

    SELECT SYSTEM$GET_AWS_SNS_IAM_POLICY('<topic_arn>');
    
    Copy

    topic_arn ist der Amazon Ressource Name (ARN) des SNS-Themas, das Sie in Ihrem Quellkonto für die ursprüngliche Pipe erstellt haben.

    Anschließend müssen Sie die neue Amazon SQS-Warteschlange für Ihr SNS-Thema abonnieren.

  4. Aktualisieren Sie die Objekte in Ihrer neuen Failover-Gruppe.

    ALTER FAILOVER GROUP my_pipe_failover_group REFRESH;
    
    Copy
  5. Abschließend wird das Zielkonto mit dem Befehl ALTER FAILOVER GROUP zum Quellkonto heraufgestuft.

    ALTER FAILOVER GROUP my_pipe_failover_group PRIMARY;
    
    Copy

    Die mypipe-Pipe beginnt damit, alle Daten zu laden, die seit der letzten Aktualisierung der Failover-Gruppe im Quellkonto bereitgestellt wurden.

    Um sicherzustellen, dass die replizierte Pipe funktioniert, führen Sie mit der COPY-Anweisung der Pipe eine Abfrage auf der Tabelle aus.

    SELECT * FROM mytable;
    
    Copy