Arbeitsbereichsreplikation¶

Wichtig

Arbeitsbereiche, die Benutzern gehören, erfordern Business Critical (BC) oder höher, um die Replikation zu unterstützen.
Failover und Failback erfordern Business Critical Edition oder höher. Wenn Sie sich über ein Upgrade informieren möchten, wenden Sie sich an den Snowflake Support.

Die Replikation trägt dazu bei, die Geschäftskontinuität sicherzustellen, indem Arbeitsbereiche und andere wichtige Objekte über mehrere Konten hinweg verfügbar gemacht werden, selbst bei Katastrophen, Ausfällen oder Zeiten der Nichtverfügbarkeit. Administratoren konfigurieren Replikationsgruppe, um Kontoobjekte und Datenbanken nach einem definierten Zeitplan von einem Primärkonto in ein oder mehrere Sekundärkonten zu kopieren.

So funktioniert die Arbeitsbereichsreplikation¶

Freigegebene Arbeitsbereiche werden repliziert, wenn sie in einer Datenbank enthalten sind, die Teil einer Replikations- oder Failover-Gruppe ist. Private Arbeitsbereiche werden repliziert, wenn ihre Eigentümer repliziert werden. In sekundären (Ziel-)Konten sind replizierte Inhalte schreibgeschützt. Arbeitsbereichsdateien sind ausführbar, können aber nicht bearbeitet werden. Um neue Abfragen zu erstellen und auszuführen, verwenden Sie im Sekundärkonto die ursprüngliche Arbeitsblätter-Oberfläche.

Die Datenbankreplikation kann auch als Failover-Gruppe konfiguriert werden, um eine hohe Verfügbarkeit zu unterstützen. Wenn eine sekundäre Failover-Gruppe zur primären Gruppe heraufgestuft wird, werden alle enthaltenen Objekte, einschließlich Arbeitsbereiche, im neuen primären Konto beschreibbar.

Weitere Informationen dazu finden Sie unter Einführung in Replikation und Failover über mehrere Konten.

LOCAL-Arbeitsbereiche¶

LOCAL-Arbeitsbereiche sind nicht Teil der Arbeitsbereichsreplikation. Arbeitsbereichsdateien verbleiben in der aktuellen Bereitstellung und werden nicht in andere Bereitstellungen kopiert oder mit diesen synchronisiert.

Wenn die Arbeitsbereichsreplikation aktiviert ist, werden alle vorhandenen Arbeitsbereiche und Dateien, die bereits in einer sekundären Bereitstellung vorhanden sind, automatisch als LOCAL gekennzeichnet. Dadurch wird sichergestellt, dass Benutzer weiterhin Zugriff auf ihre vorhandenen Arbeitsbereichsdaten in der sekundären Bereitstellung haben und diese nicht verlieren, wenn die Replikation aktiviert wird.

Einrichten der Replikation des Arbeitsbereichs¶

Um Arbeitsbereiche zu replizieren, müssen Sie die folgenden Einrichtungsaufgaben in der folgenden Reihenfolge erledigen:

Schritt 1: Replikation für das Konto aktivieren¶

Ein Benutzer mit der Rolle ORGADMIN muss die Replikation für jedes Quell- und Zielkonto in der Organisation aktivieren:

USE ROLE ORGADMIN;
SELECT SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER(
    '<organization_name>.<account_name>',
    'ENABLE_ACCOUNT_DATABASE_REPLICATION',
    'true');

Copy

Weitere Informationen dazu finden Sie unter Voraussetzung: Replikation für Konten in Ihrer Organisation aktivieren.

Schritt 2: Replikationsgruppe erstellen¶

Eine Replikationsgruppe kopiert Objekte von einem Primärkonto auf ein Sekundärkonto nach einem optional definierten Zeitplan.

Um eine Replikationsgruppe zu erstellen, geben Sie das Konto an, das den Arbeitsbereich in der Replikationsgruppe enthält:

Primärkonto¶

USE ROLE ACCOUNTADMIN;

CREATE REPLICATION GROUP my_replication_group
    OBJECT_TYPES = USERS
    ALLOWED_ACCOUNTS = org_name.secondary_account_name
    [ REPLICATION_SCHEDULE = '10 MINUTE' ]

Copy

In diesem Beispiel:

ALLOWED_ACCOUNTS – Das Sekundärkonto, auf das die Replikation erfolgen soll.
REPLICATION_SCHEDULE – Wie häufig die Replikation stattfindet (z. B. ‚10 MINUTE‘ oder ‚1 HOUR‘).

Sekundäres Konto¶

USE ROLE ACCOUNTADMIN;
CREATE REPLICATION GROUP my_replication_group
  AS REPLICA OF org_name.primary_account_name.my_replication_group;

Copy

Failover für hohe Verfügbarkeit einrichten¶

Um Failover (Heraufstufen eines sekundären Kontos zum primären) während eines Ausfalls zu aktivieren, müssen Sie eine Failover-Gruppe anstelle einer Replikationsgruppe verwenden:

Primärkonto¶

USE ROLE ACCOUNTADMIN;
CREATE FAILOVER GROUP my_failover_group
  OBJECT_TYPES = USERS
  ALLOWED_ACCOUNTS = org_name.secondary_account_name
  [ REPLICATION_SCHEDULE = '10 MINUTE' ]

Copy

Sekundäres Konto¶

USE ROLE ACCOUNTADMIN;
CREATE FAILOVER GROUP my_failover_group
  AS REPLICA OF org_name.primary_account_name.my_failover_group;

Copy

Sekundäres übernimmt, wenn primäres fehlschlägt¶

Wenn Sie die Failover-Gruppe zur primären Gruppe heraufstufen, wird der Arbeitsbereich schreibgeschützt.

Verhaltensweise von Sekundärkonten¶

Wenn Sie keinen verfügbaren Lese-/Schreib-Arbeitsbereich haben, können Sie auch zur Verwendung von Arbeitsblättern in der Snowsight zurückkehren, welche Lese- und Schreibzugriff unterstützen.

Hinweise¶

Abfrageergebnisse werden nicht repliziert – Abfrageergebnisse werden nur in dem Konto gespeichert, in dem die Abfrage ursprünglich ausgeführt wurde.
Der ausgewählte Kontext für Rolle, Warehouse, Datenbank und Schema wird nicht repliziert – Sie können diese Objekte auf Kontoebene separat replizieren, aber diese Kontexte bleiben bei den Dateien im Zielkonto nicht ausgewählt.

Einschränkungen¶

Die Git-Integration wird derzeit nach einem Failover nicht unterstützt – Wenn ein sekundäres Konto mit Arbeitsbereichen zum primären Konto heraufgestuft wird, müssen Sie die Git-Integration manuell neu konfigurieren.
Die Arbeitsbereiche im Sekundärkonto sind schreibgeschützt.

Ausführliche Informationen zum Replikationsverhalten finden Sie unter Hinweise zur Replikation.