Regionsübergreifende Replikation in Azure Cosmos DB for MongoDB (vCore)
GILT FÜR: 
MongoDB-vCore
In diesem Artikel wird die regionsübergreifende Notfallwiederherstellung (DR) in Azure Cosmos DB for MongoDB vCore dargestellt. Darüber hinaus werden Lesefunktionen der Clusterreplikate in anderen Regionen für die Skalierbarkeit von Lesevorgängen behandelt.
Mithilfe des regionsübergreifenden Features können Sie Daten von einem Cluster auf einen schreibgeschützten Cluster in einer anderen Azure-Region replizieren. Replikate werden mit asynchroner Replikationstechnologie aktualisiert. Sie können für den primären Azure Cosmos DB for MongoDB vCore-Cluster ein Clusterreplikat in einer anderen Region Ihrer Wahl haben. Im seltenen Fall eines Regionsausfalls können Sie Clusterreplikate in einer anderen Region heraufstufen, um zum neuen Lese-/Schreibzugriffscluster für den kontinuierlichen Betrieb Ihrer MongoDB-Datenbank zu werden. Anwendungen verwenden möglicherweise weiterhin dieselben Verbindungszeichenfolgen, nachdem das Clusterreplikat in einer anderen Region höhergestuft wurde, um zum neuen primären Cluster zu werden.
Replikate sind neue Cluster, die Sie ähnlich wie reguläre Cluster verwalten. Für jedes Lesereplikat werden Ihnen die bereitgestellten Computeressourcen in Form von virtuellen Kernen sowie der Speicher in GiB/Monat in Rechnung gestellt. Compute- und Speicherkosten für Replikatcluster weisen die gleiche Struktur wie die regulären Cluster und Preise der Azure-Region auf, in der sie erstellt werden.
Notfallwiederherstellung mithilfe von Clusterlesereplikaten
Die regionsübergreifende Replikation ist eine von mehreren wichtigen Säulen der Azure-Strategie für Business Continuity & Disaster Recovery (BCDR, Geschäftskontinuität und Notfallwiederherstellung). Bei der regionsübergreifenden Replikation werden die gleichen Anwendungen und Daten für den Schutz der Notfallwiederherstellung asynchron in anderen Azure-Regionen repliziert. Nicht alle Azure-Dienste replizieren automatisch Daten oder greifen automatisch auf eine ausgefallene Region zurück, um eine regionsübergreifende Replikation in eine andere aktivierte Region durchzuführen. Azure Cosmos DB for MongoDB vCore bietet die Möglichkeit, ein Clusterreplikat in einer anderen Region zu erstellen und die auf dem primären Cluster geschriebenen Daten automatisch auf dieses Replikat zu replizieren. Der Fallback zum Clusterreplikat im Falle eines Ausfalls der primären Region muss manuell eingeleitet werden.
Wenn die regionsübergreifende Replikation auf einem Azure Cosmos DB for MongoDB vCore-Cluster aktiviert ist, wird jeder Shard kontinuierlich in eine andere Region repliziert. Bei dieser Replikation wird ein Replikat der Daten in der ausgewählten Region aufbewahrt. Eine solche Replik kann als Teil des Notfallwiederherstellungsplans für den seltenen Fall verwendet werden, dass die primäre Region ausfällt. Die Replikation ist asynchron. Schreibvorgänge auf dem Shard des primären Clusters warten nicht auf den Abschluss der Replikation auf den Shard des entsprechenden Replikats, bevor sie eine Bestätigung für einen erfolgreichen Schreibvorgang senden. Die asynchrone Replikation hilft, erhöhte Latenzen bei Schreibvorgängen auf dem primären Cluster zu vermeiden.
Fortlaufende Schreib- und Lesevorgänge für Clusterreplikate und Verbindungszeichenfolgen
Die globale Lese/Schreib-Verbindungszeichenfolge in Azure Cosmos DB for MongoDB leitet Schreibvorgänge fortlaufend an den aktiven Cluster mit aktiviertem Schreibzugriff weiter. Beim Initiieren der Höherstufung eines Replikatclusters wechselt der Replikatcluster in Region B in den Schreibmodus, während der ursprüngliche primäre Cluster in Region A in den schreibgeschützten Modus wechselt. Vor der Höherstufung verweist die globale Lese/Schreib-Verbindungszeichenfolge auf den primären Cluster in Region A und wird dann aktualisiert, um auf Region B zu verweisen, da sie Schreibaufgaben übernimmt. Für Anwendungen, die die globale Lese/Schreib-Verbindungszeichenfolge verwenden, werden Schreibvorgänge während des gesamten Höherstufungssprozesses nahtlos fortgesetzt, um den unterbrechungsfreien Datenfluss aufrecht zu erhalten.
Replikatcluster sind auch für Lesevorgänge verfügbar. Es hilft, intensive Lesevorgänge vom primären Cluster auszulagern oder den Clients, die sich näher an der Replikationsregion befinden, geringere Latenzzeiten für Lesevorgänge zu bieten. Wenn die regionsübergreifende Replikation aktiviert ist, können Anwendungen die Selbstverbindungszeichenfolge des Clusterreplikats verwenden, um Lesevorgänge aus dem Clusterreplikat durchzuführen. Der primäre Cluster ist für Lese- und Schreibvorgänge über eine eigene Selbstverbindungszeichenfolge verfügbar.
Wenn Sie ein Replikat erstellen, indem Sie die regionsübergreifende Replikation aktivieren, erbt es nicht die Netzwerkeinstellungen wie z. B. Firewall-Regeln des primären Clusters. Diese Einstellungen müssen unabhängig voneinander für das Replikat eingerichtet werden. Das Replikat erbt das Administratorkonto des primären Clusters. Benutzerkonten müssen im primären Cluster verwaltet werden. Sie können eine Verbindung zum primären Cluster und seinem Replikatcluster über dieselben Benutzerkonten herstellen.
Höherstufung des Replikatclusters
Wenn eine Region ausfällt, können Sie einen Vorgang zur Notfallwiederherstellung durchführen, indem Sie Ihr Clusterreplikat in eine andere Region verschieben, damit es für Schreibvorgänge verfügbar wird. Während des Vorgangs der Höherstufung von Replikaten finden die folgenden Schritte statt:
- Schreibvorgänge auf dem Replikat in Region B werden zusätzlich zu den Lesevorgängen aktiviert. Das ehemalige Replikat wird zu einem neuen Lese-/Schreibcluster.
- Der höhergestufte Replikatcluster in Region B akzeptiert Schreibvorgänge mithilfe der eigenen Verbindungszeichenfolge und der globalen Lese/Schreib-Verbindungszeichenfolge.
- Der Cluster in Region A ist auf „schreibgeschützt“ festgelegt und behält seine Verbindungszeichenfolge bei.
Wichtig
Da die Replikation asynchron erfolgt, werden einige Daten aus dem Cluster in Region A möglicherweise nicht in Region B repliziert, wenn das Clusterreplikat in Region B höhergestuft wird. Wenn dies der Fall ist, würde die Höherstufung dazu führen, dass die nicht replizierten Daten in beiden Clustern nicht vorhanden sind.