Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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, wechselt Azure DocumentDB eingehende Verbindungen vom fehlerhaften Shard in den Standbymodus. 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 (AZ) bereitgestellt, um die Latenz zwischen den Shards zu verbessern. Die Standby-Shards werden in einer anderen Verfügbarkeitszone bereitgestellt.
Auch ohne HA-Aktivierung verfügt jeder 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 einzelner Replikatfehler auftritt, erkennt der Azure Storage-Dienst es und erstellt fehlerhafte Replikate transparent neu. Siehe Metriken auf dieser Seite zur LRS-Speicherbeständigkeit.
Wenn HA aktiviert ist , führt Azure DocumentDB einen Standby-Shard für jeden primären Shard im Cluster aus. Jeder primäre und Standby-Shard weist die gleiche Compute- und Speicherkonfiguration auf. Der Primärserver und sein Standby verwenden synchrone Replikation. Diese Art von Replikation ermöglicht es Ihnen, immer dieselben Daten zu den primären und Standby-Shards in Ihrem Cluster zu haben. Kurz gesagt, unser Dienst erkennt einen Fehler von primären Shards und wechselt zu Standby-Shards mit keinem Datenverlust.
Die Clusterverbindungszeichenfolge bleibt unabhängig von Failovers immer gleich. Dadurch kann der Dienst Änderungen an physischen Shards abstrahieren, die Anforderungen von Anwendungen erfüllen.
Wenn die hohe Verfügbarkeit in der Region auf dem Cluster aktiviert ist, wird jeder Cluster-Shard vom 99,99% Service Level Agreement (SLA) für die Verfügbarkeit abgedeckt.
Hohe Verfügbarkeit kann bei der Erstellung des Clusters aktiviert werden. Hohe Verfügbarkeit kann auch jederzeit in einem vorhandenen Azure DocumentDB-Cluster aktiviert und deaktiviert werden. Es gibt keine Datenbankausfallzeiten, wenn hohe Verfügbarkeit in einem Azure DocumentDB-Cluster aktiviert oder deaktiviert ist.
Was während eines Failovers geschieht
Jedes Shardfailover besteht aus drei Phasen: Erkennung der Nichtverfügbarkeit, Wechseln zum Standby-Shard und erneute Erstellung des Standby-Shards. 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 die Standby-Shard umgeleitet. Die synchrone Replikation zwischen den einzelnen primären und Standby-Shards stellt sicher, dass der Standby-Shard immer denselben Satz von Daten wie seine primäre Daten enthält. Dadurch können alle Failovers ohne Datenverlust ausgeführt werden. Der Wechsel zum Standbymodus erfolgt ohne Ausfallzeiten für Lesevorgänge. Schreibvorgänge erfordern möglicherweise interne Dienstüberprüfungen während der Switchphase. Diese Wiederholungen können als langsame Schreibvorgänge auf der Anwendungsseite betrachtet werden.
Nach Abschluss des Shard-Failovers ist der Cluster vollständig funktionsfähig. Der letzte Schritt, um zur ursprünglichen hoch verfügbaren Konfiguration zurückzukehren, besteht darin, die Standby-Shard neu zu erstellen. Diese Standby-Shard-Neuerstellung wird ohne Ausfallzeiten oder Leistungseinbußen auf den primären Shard durchgeführt.