Einführung in Kontoreplikation und Failover¶
Dieses Feature ermöglicht die Replikation von Objekten von einem Quellkonto in ein oder mehrere Zielkonten derselben Organisation. Replizierte Objekte in jedem Zielkonto werden als sekundäre Objekte bezeichnet und sind Replikate der primären Objekte im Quellkonto. Die Replikation wird über verschiedene Regionen und Cloudplattformen hinweg unterstützt.
Unter diesem Thema:
Unterstützung von Replikation und Failover/Failback in den Regionen¶
Die Replikation wird in allen Snowflake-Regionen auf Amazon Web Services, Google Cloud Platform und Microsoft Azure unterstützt.
Kunden können die Replikation über alle Region innerhalb einer Regionsgruppe hinweg ausführen. Wenn Sie die Replikation zwischen Regionen in verschiedenen Regionsgruppen ausführen möchten (d. h. von einer kommerziellen Snowflake-Region zu einer Snowflake-Region für Regierungsbehörden oder einer Virtual Private Snowflake-Region), wenden Sie sich an den Snowflake-Support.
Replikationsgruppen und Failover-Gruppen¶
Eine Replikationsgruppe ist eine definierte Sammlung von Objekten in einem Quellkonto, die als Einheit in ein oder mehrere Zielkonten repliziert wird. Replikationsgruppen bieten einen Nur-Lese-Zugriff auf die replizierten Objekte.
Eine Failover-Gruppe ist eine Replikationsgruppe, die auch ein Failover ausführen kann. Eine sekundäre Failover-Gruppe in einem Zielkonto bietet einen Nur-Lese-Zugriff für die replizierten Objekte. Wenn eine sekundäre Failover-Gruppe zur primären Failover-Gruppe heraufgestuft wird, ist Lese- und Schreibzugriff möglich. Jedes in der Liste der zulässigen Konten in einer Failover-Gruppe angegebene Zielkonto kann zur primären Failover-Gruppe heraufgestuft werden.
Replikations- und Failover-Gruppen bieten zeitpunktbezogene Konsistenz für die Objekte im Zielkonto. Die Objekte, die in eine Replikations- oder Failover-Gruppe aufgenommen werden können, sind unter Replizierte Objekte (unter diesem Thema) aufgeführt.
Feature-Edition-Matrix für Replikation¶
Beachten Sie, dass einige Features der Objektreplikation nur für Business Critical Edition (oder höher) verfügbar sind. In der folgenden Tabelle ist die Verfügbarkeit der Replikationsfeatures von Konto- und Datenbankobjekten für jede Snowflake-Edition aufgeführt:
Feature |
Standard |
Enterprise |
Business Critical |
VPS |
---|---|---|---|---|
Datenbankreplikation |
✔ |
✔ |
✔ |
✔ |
Freigabereplikation |
✔ |
✔ |
✔ |
✔ |
Replikationsgruppe |
✔ |
✔ |
✔ |
✔ |
Replikation von Kontoobjekten (außer Datenbanken und Freigaben) |
✔ |
✔ |
||
Failover-Gruppe |
✔ |
✔ |
||
Daten geschützt mit Tri-Secret Secure |
✔ |
✔ |
Replizierte Objekte¶
Dieses Feature unterstützt das Replizieren der unten aufgeführten Objekte. Die Replikation von Datenbanken und Freigaben ist für alle Editionen verfügbar. Die Replikation aller anderen Objekte ist nur für die Business Critical Edition (oder höher) verfügbar. Weitere Informationen zur Verfügbarkeit der Features finden Sie in dieser Tabelle.
Objekt |
Typ oder Feature |
Repliziert |
Anmerkungen |
---|---|---|---|
Datenbanken |
✔ |
||
Integrationen |
Sicherheit, API, Benachrichtigung |
✔ |
Weitere Beschränkungen und Details zu den unterstützten Typen finden Sie unter Integrationsreplikation. |
Netzwerkrichtlinien |
✔ |
||
Parameter (Kontoebene) |
✔ |
||
Ressourcenmonitore |
✔ |
||
Rollen |
✔ |
Umfasst Berechtigung, die Rollen erteilt werden, sowie Rollen, die Rollen zugewiesen werden (d. h. Hierarchien von Rollen). Wenn Benutzer und Rollen repliziert werden, werden auch die den Benutzern zugewiesenen Rollen repliziert. Das Replizieren von Datenbankrollen ist für einen zukünftigen Meilenstein dieses Features geplant. |
|
Freigaben |
✔ |
||
Benutzer |
✔ |
||
Warehouses |
✔ |
Datenbankreplikation¶
Dieses Feature unterstützt das Replizieren von Datenbanken. Ein Snapshot enthält Änderungen an den Objekten und Daten. Wenn roles
(Rollen) repliziert werden (in derselben oder einer anderen Replikations- oder Failover-Gruppe), werden bei der Datenbankaktualisierung auch die Berechtigungszuweisungen zur Sekundärdatenbank und zu den Objekten in der Datenbank (Schemas, Tabellen, Ansichten usw.) mit den Rollen im Konto synchronisiert. Weitere Details dazu finden Sie unter Berechtigungszuweisungen für Datenbankobjekte.
Replizierte Datenbankobjekte¶
Wenn eine Primärdatenbank repliziert wird, wird ein Snapshot der enthaltenen Datenbankobjekte und Daten in die Sekundärdatenbank übertragen. Einige Datenbankobjekte werden jedoch nicht repliziert. Die folgende Tabelle gibt an, welche Datenbankobjekte in eine Sekundärdatenbank repliziert werden.
Spezifische Informationen zur Verwendung dieser Objekte finden Sie unter Hinweise zur Replikation.
Objekt |
Typ oder Feature |
Repliziert |
Anmerkungen |
---|---|---|---|
Tabellen |
Permanente Tabellen |
✔ |
|
Transiente Tabellen |
✔ |
||
Temporäre Tabellen |
|||
Automatic Clustering von Clustertabellen |
✔ |
||
Externe Tabellen |
Das Erstellen oder Aktualisieren einer sekundären Datenbank wird blockiert, wenn in der primären Datenbank eine externe Tabelle vorhanden ist. . Für eine zukünftige Version der Datenbankreplikation geplant. |
||
Tabelleneinschränkungen |
✔ |
Außer wenn ein Fremdschlüssel in der Datenbank auf einen Primär- oder eindeutigen Schlüssel in einer anderen Datenbank verweist. . |
|
Sequenzen |
✔ |
||
Ansichten |
Ansichten |
✔ |
Wenn eine Ansicht auf irgendein Objekt in einer anderen Datenbank verweist (z. B. Tabellenspalten, andere Ansichten, UDFs oder Stagingbereiche), . müssen beide Datenbanken repliziert werden. |
Materialisierte Ansichten |
✔ |
||
Sichere Ansichten |
✔ |
||
Dateiformate |
✔ |
||
Stagingbereiche |
Stagingbereiche |
Geplant für eine zukünftige Version der Datenbankreplikation. |
|
Temporäre Stagingbereiche |
|||
Pipes |
Geplant für eine zukünftige Version der Datenbankreplikation. |
||
Gespeicherte Prozeduren |
✔ |
Weitere Details dazu finden Sie unter Replikation von gespeicherten Prozeduren und benutzerdefinierten Funktionen (UDFs). |
|
Streams |
✔ |
Weitere Details dazu finden Sie unter Replikation und Streams. |
|
Aufgaben |
✔ |
Weitere Details dazu finden Sie unter Replikation und Aufgaben. |
|
UDFs |
✔ |
Weitere Details dazu finden Sie unter Replikation von gespeicherten Prozeduren und benutzerdefinierten Funktionen (UDFs). |
|
Richtlinien |
Sicherheit auf Spaltenebene (Maskieren) |
✔ |
Weitere Informationen zu Maskierungs-, Zeilenzugriffs- und Tag-basierte Maskierungsrichtlinien finden Sie unter Hinweise zur Richtlinienreplikation. |
Zeilenzugriffsrichtlinien |
✔ |
||
Tag-basierte Maskierungsrichtlinien |
✔ |
||
Sitzungsrichtlinien |
✔ |
Weitere Informationen zu Sitzungs- und Kennwortrichtlinien finden Sie unter Replikations- und Sicherheitsrichtlinien. |
|
Kennwortrichtlinien |
✔ |
||
Tags |
Objekt-Tagging |
✔ |
Weitere Informationen zu Tags finden Sie unter Replikation und Tags. |
Database Replication and Encryption¶
Snowflake protects metadata and data sets at rest and in transit between the source and target accounts. The account master key (AMK) encrypts the key hierarchy within the account as shown in the hierarchical key model. Snowflake encrypts replicated data in the target account using the account master key and the key hierarchy in the target account, regardless of whether you enable Tri-Secret Secure in the target account.
When you enable Tri-Secret Secure in the target account, Snowflake uses the composite master key and the corresponding key hierarchy in the target account to encrypt the data. Note that target accounts do not have Tri-Secret Secure enabled by default; you must enable this feature.
Weitere Informationen zur Datenverschlüsselung in Snowflake finden Sie unter Hinweise zur End-to-End-Verschlüsselung in Snowflake.
Integrationsreplikation¶
Die Kontoreplikation unterstützt die Replikation der Sicherheitsintegrationen für die folgenden Features:
Sicherheitsintegrationen der folgenden Typen:
Verbundauthentifizierung und SSO (d. h. SAML2)
SCIM
Snowflake OAuth
External OAuth
Weitere Informationen zu Sicherheitsintegrationen finden Sie unter Replikation von Sicherheitsintegrationen und Netzwerkrichtlinien über mehrere Konten hinweg.
API integrations.
Nachdem Sie API-Integrationen in ein Zielkonto repliziert haben, müssen Sie den replizierten externen Funktionen Zugriff auf den Remotedienst gewähren. Weitere Details dazu finden Sie unter Remotedienst für API-Integrationen aktualisieren.
Benachrichtigungsintegrationen der folgenden Typen:
TYPE = EMAIL
TYPE = QUEUE mit DIRECTION = OUTBOUND
Speicherintegrationen werden derzeit nicht unterstützt, sind aber für ein zukünftiges Release geplant.
Replikation von Netzwerkrichtlinien¶
Dieses Feature unterstützt das Replizieren von Netzwerkrichtlinien.
Weitere Details dazu finden Sie unter Replikation von Sicherheitsintegrationen und Netzwerkrichtlinien über mehrere Konten hinweg.
Replikation von Parametern¶
Dieses Feature unterstützt das Replizieren von Parametern auf Kontoebene und von Objektparametern. Objektparameter werden repliziert, wenn das Objekt in die Replikationsgruppe aufgenommen wird. Wenn zum Beispiel WAREHOUSES
repliziert werden, werden Warehouse-spezifische Parameter (z. B. STATEMENT_TIMEOUT_IN_SECONDS) repliziert. Eine vollständige Liste finden Sie unter Object Parameters.
Das Replizieren von Parametern auf Kontoebene umfasst alle Account Parameters und die für das Konto festgelegten Parameter. Parameter auf Kontoebene (z. B. DATA_RETENTION_TIME_IN_DAYS) werden repliziert, wenn ACCOUNT PARAMETERS
in der Liste der Objekttypen einer Replikationsgruppe enthalten ist.
Replikation von Ressourcenmonitoren¶
Dieses Feature unterstützt das Replizieren von Ressourcenmonitoren einschließlich der Berechtigungen, die Rollen für Ressourcenmonitore erteilt wurden. Ein sekundärer Ressourcenmonitor verwendet denselben Zeitplan für das Zurücksetzen von Kontingenten wie sein primärer Ressourcenmonitor. Wenn beispielsweise das Kontingent des primären Ressourcenmonitors am Ersten des Monats zurückgesetzt wird und der sekundäre Ressourcenmonitor zum ersten Mal am 15. des Monats repliziert wird, wird sein Kontingent am 1. des nächsten Monats zusammen mit dem primären Monitor zurückgesetzt.
Das Einrichten von E-Mail-Benachrichtigungen wird nicht repliziert, d. h. Kontoadministratoren müssen E-Mail-Benachrichtigungen für jedes Zielkonto einrichten. Siehe Aktivieren des Empfangs von Benachrichtigungen für Kontoadministratoren. Die Replikation der Benachrichtigungskonfiguration ist für ein zukünftiges Release geplant.
Rollenreplikation¶
Dieses Feature unterstützt das Replizieren von Rollen einschließlich der Rollenhierarchien. Rollenobjekte müssen repliziert werden, um Zugriffsrechte zu replizieren. Replizierte Zugriffsrechte sind unter Replikation von Rollen und Berechtigungszuweisungen (unter diesem Thema) aufgeführt.
Bemerkung
Alle Rollen werden repliziert, auch die Rolle ORGADMIN.
Benutzerreplikation¶
Dieses Feature unterstützt das Replizieren von Benutzern und deren Eigenschaften in Zielkonten, die folgenden Benutzerauthentifizierungsmethoden sowie das Bereitstellen von Benutzern und Gruppen mit SCIM:
Authentifizierungsmethode |
Funktioniert in Zielkonten |
Anmerkungen |
---|---|---|
Kennwort |
✔ |
|
Kennwort mit MFA (Mehrstufige Authentifizierung) |
✔ |
Benutzer, die im Quellkonto für MFA angemeldet sind, müssen sich für eine Anmeldung in jedem Zielkonto separat für MFA anmelden. |
✔ |
Benutzer, die im Quellkonto für MFA angemeldet sind, müssen sich für eine Anmeldung in jedem Zielkonto separat für MFA anmelden. |
|
Schlüsselpaar-Authentifizierung |
✔ |
|
✔ |
Weitere Informationen zur Replikation von Sicherheitsintegrationen mit Verbund-SSO (d. h. SAML2) finden Sie unter Replikation von Sicherheitsintegrationen und Netzwerkrichtlinien über mehrere Konten hinweg. |
|
✔ |
Weitere Informationen zur Replikation von OAuth-Sicherheitsintegrationen finden Sie unter Replikation von Sicherheitsintegrationen und Netzwerkrichtlinien über mehrere Konten hinweg. |
|
✔ |
Weitere Informationen zur Replikation von OAuth-Sicherheitsintegrationen finden Sie unter Replikation von Sicherheitsintegrationen und Netzwerkrichtlinien über mehrere Konten hinweg. |
|
✔ |
Weitere Informationen zur Replikation von SCIM-Sicherheitsintegrationen finden Sie unter Replikation von Sicherheitsintegrationen und Netzwerkrichtlinien über mehrere Konten hinweg. |
Bemerkung
Wenn USERS
- und ROLES
-Objekte in ein Zielkonto repliziert werden, sind diese Objekttypen im Zielkonto schreibgeschützt und können nicht geändert werden. Benutzer und Rollen müssen im Quellkonto erstellt und dann in jedes Zielkonto repliziert werden. Weitere Informationen dazu finden Sie unter Replikation und schreibgeschützte Sekundärobjekte (unter diesem Thema).
Warehouse-Replikation¶
Dieses Feature unterstützt das Replizieren von Warehouses einschließlich der Berechtigungen, die Rollen für Warehouses erteilt wurden (wenn roles
repliziert werden). Der Status des primären Warehouses wird nicht repliziert. Warehouses werden im angehaltenen Zustand in jedes Zielkonto repliziert und können dann im Zielkonto fortgesetzt werden.
Replikation von Rollen und Berechtigungszuweisungen¶
Um für Rollen Berechtigungszuweisungen zu Objekten zu replizieren, müssen die Rollen vom Quellkonto in das Zielkonto repliziert werden. Um Rollen einer Replikations- oder Failover-Gruppe zu replizieren, müssen Sie roles
in die Liste object_types
aufnehmen. Rollen können sich in einer separaten Replikations- oder Failover-Gruppe befinden, die von den Datenobjekten getrennt ist, für die die Berechtigungen erteilt wurden.
Wenn roles
repliziert werden, werden Berechtigungszuweisungen zu Objekten nur in folgenden Fällen in ein Zielkonto repliziert:
Die Berechtigung wurde vom Objekteigentümer erteilt oder indirekt über eine Rolle, der die Berechtigung mit dem Parameter WITH GRANT OPTION vom Eigentümer des Objekts erteilt wurde.
Sowohl die Rolle des Berechtigungsempfängers als auch die Rolle des Berechtigungsgebers einer Berechtigungszuweisung befinden sich im Zielkonto.
Das Objekt wird repliziert (d. h. der Objekttyp ist in der Liste
object_types
enthalten).
Andernfalls wird die Berechtigungszuweisung für das Objekt nicht repliziert.
Bemerkung
Wenn eine Rolle gelöscht wird, die die OWNERSHIP-Berechtigung für eine aktive Pipe im Zielkonto hat, schlägt die Aktualisierungsoperation fehl.
Berechtigungen für Replikationsgruppen und Failover-Gruppen (siehe Replikationsberechtigungen unter diesem Thema) werden derzeit nicht repliziert. Wenn die REPLICATE- oder FAILOVER-Berechtigung für Replikationsgruppen bzw. Failover-Gruppen erteilt wurde, müssen diese Berechtigungen in den Quellkonten und in den Zielkonten erteilt werden.
Berechtigungszuweisungen für Datenbankobjekte¶
Wenn roles
(Rollen) und databases
(Datenbanken) in ein Zielkonto (in derselben oder einer anderen Replikations- oder Failover-Gruppe) repliziert werden, werden bei der Aktualisierung einer Sekundärdatenbank die Berechtigungszuweisungen zur Datenbank und zu den Objekten in der Datenbank (Schemas, Tabellen, Ansichten usw.) mit den vorhandenen Rollen im Zielkonto (d. h. den Rollen, die in das Zielkonto repliziert wurden) synchronisiert. Beachten Sie, dass nur Berechtigungszuweisungen zu Objekten synchronisiert werden, die von der Datenbankreplikation unterstützt werden. Eine Liste der Objekte finden Sie unter Replizierte Datenbankobjekte.
Die Replikation folgender Datenbankobjekte wird derzeit nicht unterstützt. Infolgedessen werden auch die Berechtigungszuweisungen zu diesen Objekten nicht repliziert:
Stagingbereiche
Pipes
Externe Tabellen
Zukünftige Berechtigungszuweisungen für Objekte¶
Wenn Rollen in das Zielkonto repliziert werden, werden zukünftige Berechtigungszuweisungen, die auf Datenbank- oder Schemaebene erteilt wurden, in das Zielkonto repliziert. Dies gilt auch für zukünftige Berechtigungszuweisungen zu Objekten, für die die Replikation nicht unterstützt wird. So wird beispielsweise die Replikation von Stagingbereichen noch nicht unterstützt, aber es werden zukünftige Berechtigungszuweisungen zu Stagingbereichen repliziert. Wenn Sie einen Stagingbereich in einem Zielkonto erstellen, werden den zukünftigen Stagingbereiche die Berechtigungen wie vorgesehen zugewiesen.
Objekterstellung und Eigentümerschaft¶
Wenn bei der Aktualisierung des Quellkontos in einem Zielkonto neue Objekte erstellt werden, aber die Rollen nicht in das Zielkonto repliziert werden, wird die OWNERSHIP-Berechtigung für die neuen Objekte der Rolle ACCOUNTADMIN zugewiesen.
Falls Rollen in das Zielkonto repliziert werden, wird beim nächsten Replizieren der Rollen die OWNERSHIP-Berechtigung im Zielkonto der gleichen Rolle zugewiesen, welche die OWNERSHIP-Berechtigung im Quellkonto hatte. Rollen können gleichzeitig mit den neuen Objekten in das Zielkonto repliziert werden, wenn sich Objekte und Rollen in der gleichen Replikationsgruppe (oder Failover-Gruppe) befinden.
Benutzer, der Objekte in einem Zielkonto aktualisiert¶
Ein Benutzer, der den Befehl ALTER FAILOVER GROUP … REFRESH ausführt, um Objekte in einem Zielkonto aus einem Quellkonto zu aktualisieren, muss eine Rolle mit der Berechtigung REPLICATE für die Failover-Gruppe haben. Snowflake schützt diesen Benutzer im Zielkonto, indem folgende Szenarios fehlschlagen:
Wenn der Benutzer im Quellkonto nicht vorhanden ist, schlägt die Aktualisierungsoperation fehl.
Wenn der Benutzer im Quellkonto vorhanden ist, ihm aber keine Rolle mit der Berechtigung REPLICATE zugewiesen wurde, schlägt die Aktualisierungsoperation fehl.
Replikationsplan¶
Als Best Practice empfiehlt Snowflake das Erstellen eines Zeitplans für automatische Aktualisierungen unter Verwendung des Parameters REPLICATION_SCHEDULE. Der Zeitplan kann beim Erstellen einer neuen Replikations- oder Failover-Gruppe mit CREATE <Objekt> oder später (mit ALTER <Objekt>) definiert werden.
Wenn eine sekundäre Replikations- oder Failover-Gruppe erstellt wird, wird automatisch eine erste Aktualisierung ausgeführt. Die nächste Aktualisierung wird dann auf Grundlage des Startzeitpunkts der vorherigen Aktualisierung und des Planungsintervalls oder des nächsten gültigen Zeitpunkts auf Grundlage des Cron-Ausdrucks geplant. Wenn beispielsweise das Aktualisierungsintervall 10 Minuten beträgt und die vorherige Aktualisierungsoperation (entweder eine geplante Aktualisierung oder eine manuell ausgelöste Aktualisierung) um 12:01 Uhr beginnt, ist die nächste Aktualisierung für 12:11 Uhr geplant.
Snowflake stellt sicher, dass zu jedem Zeitpunkt nur eine Aktualisierung ausgeführt wird. Wenn eine Aktualisierung noch ausgeführt wird, wenn die nächste Aktualisierung geplant ist, wird der Start der nächsten Aktualisierung so lange verzögert, bis die in Ausführung befindliche Aktualisierung abgeschlossen ist. Wenn z. B. eine Aktualisierung so geplant ist, dass sie jede Stunde 15 Minuten nach der vollen Stunde ausgeführt wird, und die vorherige Aktualisierung um 12:16 abgeschlossen ist, wird die nächste Aktualisierung so geplant, dass die Ausführung nach Abschluss der vorhergehende Aktualisierung erfolgt.
Geplante Replikation anhalten und fortsetzen¶
Eine sekundäre Failover-Gruppe kann nicht zur primären Gruppe heraufgestuft werden, wenn gerade eine Aktualisierung ausgeführt wird. Um einen ordnungsgemäßes Failover sicherzustellen, halten Sie die geplante Replikation im Zielkonto an. Nach Abschluss des Failovers setzen Sie die geplante Replikation fort. Weitere Informationen zur Syntax finden Sie unter ALTER FAILOVER GROUP.
Bemerkung
Das Anhalten der geplanten Replikation hat keine Auswirkungen auf eine Aktualisierungsoperation, die gerade ausgeführt wird. Es wird nur der Zeitplan angehalten, sodass nach Abschluss der aktuellen Aktualisierung keine weiteren Aktualisierungen geplant sind.
Replikation in Konten mit niedrigeren Editionen¶
Wenn eine der folgenden Bedingungen erfüllt ist, zeigt Snowflake eine Fehlermeldung an:
Eine primäre Replikationsgruppe, die nur Datenbank- und/oder Freigabeobjekte enthält, befindet sich in einem Business Critical-Konto (oder höher), aber eines oder mehrere der zur Replikation genehmigten Konten weisen niedrigere Editionen auf. Die Business Critical Edition ist für Snowflake-Konten mit äußerst sensiblen Daten vorgesehen.
Eine primäre Replikations- oder Failover-Gruppe mit beliebigen Objekttypen befindet sich in einem Business Critical-Konto (oder höher), und es besteht eine unterzeichnete Geschäftspartner-Vereinbarung zur Speicherung von PHI-Daten in dem Konto gemäß HIPAA- und HITRUST CSF-Vorschriften. Allerdings besteht für eines oder mehrere der zur Replikation aktivierten Konten keine solche Vereinbarung, unabhängig davon, ob es sich um Business Critical-Konten (oder höhere) handelt.
Dieses Verhalten wird implementiert, um zu verhindern, dass Kontoadministratoren von Business Critical-Konten (oder höher) versehentlich vertrauliche Daten auf Konten mit niedrigeren Editionen replizieren.
Ein Kontoadministrator (ein Benutzer mit der Rolle ACCOUNTADMIN) oder ein Benutzer mit einer Rolle mit CREATE REPLICATION GROUP/CREATE FAILOVER GROUP- oder OWNERSHIP-Berechtigung kann dieses Standardverhalten überschreiben, indem beim Ausführen der CREATE <Objekt>- oder ALTER <Objekt>-Anweisung die IGNORE EDITION CHECK-Klausel eingefügt wird. Wenn IGNORE EDITION CHECK festgelegt ist, kann in diesen spezifischen Szenarios die primäre Replikations- oder Failover-Gruppe in die angegebenen Konten mit niedrigerer Snowflake-Edition repliziert werden.
Bemerkung
Failover-Gruppen können nur in einem Konto mit Business Critical Edition (oder höher) erstellt werden. Daher können Failover-Gruppen auch nur in ein Konto mit Business Critical Edition (oder höher) repliziert werden.