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.
VAN TOEPASSING OP:
MongoDB vCore
Dit artikel bevat gedetailleerde informatie over regionale tolerantie met beschikbaarheidszones en herstel na noodgevallen tussen regio's en bedrijfscontinuïteit voor Azure Cosmos DB voor MongoDB vCore.
Zie Azure-betrouwbaarheid voor een architectuuroverzicht van betrouwbaarheid in Azure.
Ondersteuning voor beschikbaarheidszone
Beschikbaarheidszones zijn fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.
Zie Wat zijn beschikbaarheidszones in Azure voor meer informatie over beschikbaarheidszones?
Als u ondersteuning voor beschikbaarheidszones wilt krijgen, moet u Hoge beschikbaarheid (HA) inschakelen.
Hoge beschikbaarheid voorkomt dat databases uitvallen door standby-replica's van elke shard in een cluster te onderhouden. Als een shard uitvalt, schakelt Azure Cosmos DB voor MongoDB vCore binnenkomende verbindingen van de mislukte shard naar de stand-byreplica over.
Wanneer Hoge Beschikbaarheid is ingeschakeld in een regio die beschikbaarheidszones ondersteunt, worden HA-replica-shards toegewezen in een andere beschikbaarheidszone dan die van hun primaire shards. HA-replica's ontvangen geen aanvragen van clients, tenzij hun primaire shard mislukt.
Wanneer HA is uitgeschakeld, heeft elke shard een eigen lokaal redundante opslag (LRS) met drie synchrone replica's die worden onderhouden door de Azure Storage-service. Als er één replicafout optreedt, detecteert de Azure Storage-service de fout en maakt de relevante gegevens transparant opnieuw. Zie Overzicht van redundantieopties voor LRS-opslagduurzaamheid. In het geval van een regiofout loopt u echter het risico op uitgebreide downtime en mogelijk gegevensverlies.
Een resource maken waarvoor beschikbaarheidszones zijn ingeschakeld
Als u beschikbaarheidszones wilt inschakelen, moet u hoge beschikbaarheid (HA) inschakelen bij het maken van een cluster of in de sectie Schaal van een bestaand cluster in Azure Portal.
Herstel na noodgevallen en bedrijfscontinuïteit tussen regio's
Herstel na noodgevallen (DR) verwijst naar procedures die organisaties gebruiken om te herstellen van gebeurtenissen met hoge impact, zoals natuurrampen of mislukte implementaties die leiden tot downtime en gegevensverlies. Ongeacht de oorzaak is de beste oplossing voor een noodgeval een goed gedefinieerd en getest DR-plan en een toepassingsontwerp dat actief dr ondersteunt. Zie Aanbevelingen voor het ontwerpen van een strategie voor herstel na noodgevallenvoordat u begint met het maken van uw plan voor herstel na noodgevallen.
Voor DR maakt Microsoft gebruik van het model voor gedeelde verantwoordelijkheid. In dit model zorgt Microsoft ervoor dat de basisinfrastructuur en platformservices beschikbaar zijn. Veel Azure-services repliceren echter niet automatisch gegevens of vallen terug van een mislukte regio om kruislings te repliceren naar een andere ingeschakelde regio. Voor deze services bent u verantwoordelijk voor het instellen van een plan voor herstel na noodgevallen dat geschikt is voor uw workload. De meeste diensten op het Azure-platform als een service (PaaS) bieden functies en richtlijnen ter ondersteuning van disaster recovery. U kunt servicespecifieke functies gebruiken om snelle herstelbewerkingen te ondersteunen en uw noodherstelplan te ontwikkelen.
Azure Cosmos DB voor MongoDB vCore biedt geen ingebouwde automatische failover of herstel na noodgevallen. Het plannen van hoge beschikbaarheid is een kritieke stap wanneer uw oplossing wordt geschaald.
Herstel na noodgevallen in geografie met één regio
Als u uw uptime wilt maximaliseren, moet u vooruitgaan om bedrijfscontinuïteit te behouden en voorbereidingen te treffen voor herstel na noodgevallen met Azure Cosmos DB voor MongoDB vCore.
Hoewel Azure-services zijn ontworpen om de uptime te maximaliseren, kunnen er niet-geplande servicestoringen optreden. Een plan voor herstel na noodgevallen zorgt ervoor dat u een strategie hebt voor het afhandelen van regionale servicestoringen.
Azure Cosmos DB voor MongoDB vCore maakt automatisch back-ups van uw gegevens met regelmatige tussenpozen. De automatische back-ups worden gemaakt zonder dat dit van invloed is op de prestaties of beschikbaarheid van de databasebewerkingen. Alle back-ups worden automatisch op de achtergrond uitgevoerd en afzonderlijk van de brongegevens in een opslagservice opgeslagen. Deze automatische back-ups zijn handig in scenario's wanneer u per ongeluk resources verwijdert of wijzigt en later de oorspronkelijke versies vereist.
Automatische back-ups worden in verschillende intervallen bewaard op basis van of het cluster momenteel actief of onlangs is verwijderd.
Bewaarperiode | |
---|---|
Actieve clusters |
35 dagen |
Verwijderde clusters |
7 dagen |
Ontwerpen voor hoge beschikbaarheid
Hoge beschikbaarheid (HA) moet zijn ingeschakeld voor kritieke Azure Cosmos DB voor MongoDB vCore-clusters waarop productieworkloads worden uitgevoerd. In een cluster met hoge beschikbaarheid fungeert elke shard als een primaire shard samen met een hot-standby shard die in een andere beschikbaarheidszone is geplaatst. Replicatie tussen de primaire en de secundaire shard is standaard synchroon. Wijzigingen in de database blijven behouden op zowel de primaire als de secundaire (hot-stand-by) shards voordat een reactie van de database wordt ontvangen.
De service onderhoudt gezondheidscontroles en hartslagen voor elke primaire en secundaire shard van het cluster. Als een primaire shard niet meer beschikbaar is vanwege een zone- of regionale storing, wordt de secundaire shard automatisch gepromoveerd tot de nieuwe primaire en wordt een volgende secundaire shard gebouwd voor de nieuwe primaire. Als een secundaire shard niet meer beschikbaar is, maakt de service automatisch een nieuwe secundaire shard met een volledige kopie van gegevens van de primaire.
Als de service een overschakeling van de primaire naar de secundaire shard activeert, worden verbindingen ongemerkt en naadloos naar de nieuwe primaire shard gerouteerd.
Synchrone replicatie tussen de primaire en secundaire shards garandeert geen gegevensverlies als er een failover is.
Volgende stappen
- Lees meer over functiecompatibiliteit met MongoDB.
- Bekijk de opties voor het migreren van MongoDB naar Azure Cosmos DB voor MongoDB vCore
- Ga aan de slag door een account te maken.