Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Hoge beschikbaarheid in regio's (HA) voorkomt downtime van databases door stand-byreplica's van elke shard in een cluster te onderhouden. Als een shard om welke reden dan ook niet meer reageert, schakelt Azure DocumentDB binnenkomende verbindingen van de mislukte shard over naar de stand-by. Wanneer er een failover plaatsvindt, hebben gepromoveerde shards altijd nieuwe gegevens via synchrone replicatie.
Alle primaire shards in een cluster worden ingericht in één beschikbaarheidszone (AZ) voor een betere latentie tussen de shards. De standby-shards worden voorzien in een andere beschikbaarheidszone.
Zelfs zonder HA ingeschakeld, heeft elke shard zijn eigen lokaal redundante opslag (LRS) met drie synchrone replica's die worden onderhouden door de Azure Storage-service. Alle drie de replica's bevinden zich in de Azure-regio van het cluster. Als er één replicafout optreedt, detecteert de Azure Storage-service deze en maakt de mislukte replica transparant opnieuw. Zie metrische gegevens op deze pagina voor de duurzaamheid van LRS-opslag.
Wanneer HA is ingeschakeld, draait Azure DocumentDB een stand-by-shard voor elke primaire shard in het cluster. Elke primaire en stand-by-shard heeft dezelfde reken- en opslagconfiguratie. De primaire en de stand-by maken gebruik van synchrone replicatie. Met dit type replicatie kunt u altijd dezelfde gegevens op de primaire en stand-by-shards in uw cluster hebben. In een notendop detecteert onze service een fout op primaire shards en voert een failover uit naar stand-by-shards zonder gegevensverlies.
De clusterverbindingsreeks blijft altijd hetzelfde, ongeacht failovers. Hierdoor kan de service wijzigingen in fysieke shards abstraheren die aanvragen van toepassingen verwerken.
Wanneer hoge beschikbaarheid in regio's is ingeschakeld op het cluster, wordt elke cluster-shard gedekt door de SLA (Service Level Agreement) van 99,99% voor beschikbaarheid.
Hoge beschikbaarheid kan worden ingeschakeld tijdens het maken van clusters. Hoge beschikbaarheid kan ook op elk gewenst moment worden ingeschakeld en uitgeschakeld op een bestaand Azure DocumentDB-cluster. Er is geen downtime voor databases wanneer hoge beschikbaarheid is ingeschakeld of uitgeschakeld op een Azure DocumentDB-cluster.
Wat gebeurt er tijdens een failover?
Elke shardfailover bestaat uit drie fasen: Detectie van niet-beschikbaarheid, overschakelen naar de stand-by-shard en het opnieuw maken van de stand-by-shard. De service voert doorlopende bewaking van beschikbaarheid uit voor elke primaire en stand-by-shard in het cluster door periodieke statuscontrole uit te voeren. Wanneer de statuscontrole betrouwbaar aangeeft dat de shard niet meer reageert en als mislukt moet worden verklaard, wordt de daadwerkelijke overgang naar de stand-by shard gestart.
Tijdens de schakelfase worden lees- en schrijfbewerkingen van databases omgeleid naar de stand-by-shard. Synchrone replicatie tussen elke primaire en stand-by-shard zorgt ervoor dat de stand-by-shard altijd dezelfde set gegevens heeft als de primaire. Hierdoor kunnen alle failovers worden uitgevoerd zonder gegevensverlies. De switch naar stand-by wordt uitgevoerd zonder uitvaltijd voor leesbewerkingen. Schrijfbewerkingen vereisen mogelijk nieuwe pogingen van interne services tijdens de switchfase. Deze herhalingen kunnen worden gezien als schrijfsnelheidvertraging aan toepassingszijde.
Zodra de shard-failover is voltooid, is het cluster volledig operationeel. De laatste stap om terug te keren naar de oorspronkelijke configuratie met hoge beschikbaarheid is het opnieuw maken van de stand-by-shard. Deze stand-by-shard wordt opnieuw gemaakt zonder uitvaltijd of invloed op de prestaties van de primaire shard.