Hochverfügbarkeit in Azure Cosmos DB for MongoDB vCore
GILT FÜR: 
MongoDB-vCore
Regionsinterne Hochverfügbarkeit (High Availability, HA) vermeidet Datenbankdowntime, indem Standbyreplikate aller Shards in einem Cluster aufrechterhalten werden. Wenn ein Shard aus irgendeinem Grund nicht mehr reagiert, schaltet Azure Cosmos DB for MongoDB vCore eingehende Verbindungen vom fehlerhaften Shard auf das Standbyreplikat um. Bei einem Failover verfügen höhergestufte Shards durch die synchronen Replikation immer über aktuelle Daten.
Alle primären Shards in einem Cluster werden in einer Verfügbarkeitszone bereitgestellt, um die Wartezeit zwischen den Shards zu verkürzen. Die Standbyshards werden in einer anderen Verfügbarkeitszone bereitgestellt.
Auch ohne aktivierte Hochverfügbarkeit verfügt jede Shard über einen eigenen lokal redundanten Speicher (LRS) mit drei synchronen Replikaten, die vom Azure Storage-Dienst verwaltet werden. Alle drei Replikate befinden sich in der Azure-Region des Clusters. Wenn ein einzelnes Replikat ausfällt, erkennt der Azure Storage-Dienst dies und erstellt das fehlerhafte Replikat transparent neu. Informationen zur Lebensdauer des lokal redundanter Speichers finden Sie auf dieser Seite unter Metriken.
Wenn Hochverfügbarkeit aktiviert ist, führt Azure Cosmos DB for MongoDB vCore einen Standbyshard für jeden primären Shard im Cluster aus. Jeder primäre Shard und jeder Standbyshard weist die gleiche Compute- und Speicherkonfiguration auf. Der Primärshard und sein Standbyshard verwenden synchrone Replikation. Durch diese Art der Replikation sind im primären Shard und im Standbyshard in Ihrem Cluster immer dieselben Daten vorhanden. Kurz gesagt erkennt unser Dienst einen Fehler in primären Shards und führt ohne Datenverlust ein Failover auf den Standby aus.
Die Clusterverbindungszeichenfolge bleibt unabhängig von Failovern immer gleich. Dadurch kann der Dienst Änderungen an physischen Shards abstrahieren, die Anforderungen von Anwendungen bedienen.
Wenn regionsinterne Hochverfügbarkeit auf dem Cluster aktiviert ist, gilt für jeden Cluster-Shard das SLA (Vereinbarung zum Servicelevel) für die Verfügbarkeit von 99,99 %.
Hochverfügbarkeit kann zum Zeitpunkt der Clustererstellung aktiviert werden. Hochverfügbarkeit kann auch jederzeit in einem vorhandenen Azure Cosmos DB for MongoDB vCore-Cluster aktiviert und deaktiviert werden. Es gibt keine Datenbankdowntime, wenn Hochverfügbarkeit für einen Azure Cosmos DB for MongoDB vCore-Cluster aktiviert oder deaktiviert ist.
Was geschieht bei einem Failover?
Jedes Shardfailover besteht aus drei Phasen: Erkennung der Nichtverfügbarkeit, Wechsel zum Standbyshard und erneute Erstellung des Standbyshards. Der Dienst überwacht durch eine regelmäßige Integritätsprüfung fortlaufend die Verfügbarkeit für jeden primären Shard und Standbyshard im Cluster. Wenn die Integritätsprüfung zuverlässig angibt, dass der Shard nicht mehr reagiert und als fehlgeschlagen deklariert werden muss, wird ein tatsächliches Failover (Wechsel) zum Standbyshard initiiert.
Während der Umstellungsphase werden Lese- und Schreibvorgänge der Datenbank an den Standbyshard umgeleitet. Die synchrone Replikation zwischen den einzelnen primären Shards und Standbyshards stellt sicher, dass der Standbyshard immer denselben Satz von Daten wie der primäre Shard enthält. Dadurch können alle Failover ohne Datenverlust ausgeführt werden. Der Wechsel zum Standbyshard erfolgt ohne Downtime für Lesevorgänge. Schreibvorgänge erfordern möglicherweise Wiederholungsversuche des internen Diensts während des Wechsels. Diese Wiederholungen können als langsame Schreibvorgänge auf der Anwendungsseite betrachtet werden.
Nach Abschluss des Shardfailovers ist der Cluster vollständig funktionsfähig. Der letzte Schritt, um zur ursprünglichen hochverfügbaren Konfiguration zurückzukehren, besteht darin, den Standbyshard neu zu erstellen. Diese Neuerstellung des Standbyshards wird ohne Downtime oder Leistungseinbußen auf dem primären Shard durchgeführt.