Delen via


Replicatie tussen regio's in Azure Cosmos DB voor MongoDB vCore

VAN TOEPASSING OP: MongoDB vCore

In dit artikel worden herstel na noodgevallen in meerdere regio's beschreven voor Azure Cosmos DB voor MongoDB vCore. Het omvat ook leesmogelijkheden van de clusterreplica's in andere regio's voor schaalbaarheid van leesbewerkingen.

Met de functie replicatie tussen regio's kunt u gegevens van een cluster repliceren naar een alleen-lezen cluster in een andere Azure-regio. Replica's worden bijgewerkt met asynchrone replicatietechnologie. U kunt één clusterreplica in een andere regio van keuze hebben voor het primaire Azure Cosmos DB voor MongoDB vCore-cluster. In zeldzame gevallen van een storing in de regio kunt u de clusterreplica in een andere regio promoveren tot het nieuwe read-write-cluster voor continue werking van uw MongoDB-database. Toepassingen kunnen dezelfde verbindingsreeks blijven gebruiken nadat de clusterreplica in een andere regio wordt gepromoveerd tot het nieuwe primaire cluster.

Replica's zijn nieuwe clusters die u net als reguliere clusters beheert. Voor elke leesreplica wordt u gefactureerd voor de ingerichte rekenbewerkingen in vCores en opslag in GB/maand. Berekenings- en opslagkosten voor replicaclusters hebben dezelfde structuur als de normale clusters en prijzen van de Azure-regio waar ze worden gemaakt.

Herstel na noodgevallen met behulp van leesreplica's van clusters

Replicatie tussen regio's is een van de belangrijkste pijlers in de BCDR-strategie (Business Continuity and Disaster Recovery) van Azure. Replicatie tussen regio's replicatie repliceert asynchroon dezelfde toepassingen en gegevens in andere Azure-regio's voor herstel na noodgevallen. Niet alle Azure-services repliceren automatisch gegevens of vallen automatisch terug van een mislukte regio om kruislings te repliceren naar een andere ingeschakelde regio. Azure Cosmos DB voor MongoDB vCore biedt een optie om een clusterreplica in een andere regio te maken en gegevens te laten schrijven op het primaire cluster die automatisch naar die replica worden gerepliceerd. De terugval naar de clusterreplica als er een storing in de primaire regio is, moet handmatig worden gestart.

Wanneer replicatie tussen regio's is ingeschakeld op een Azure Cosmos DB voor MongoDB vCore-cluster, wordt elke shard continu gerepliceerd naar een andere regio. Deze replicatie onderhoudt een replica van gegevens in de geselecteerde regio. Een dergelijke replica is gereed om te worden gebruikt als onderdeel van een noodherstelplan in een zeldzaam geval van een storing in de primaire regio. Replicatie is asynchroon. Schrijfbewerkingen op de shard van het primaire cluster wachten niet op voltooide replicatie naar de shard van de bijbehorende replica voordat u een bevestiging van een geslaagde schrijfbewerking verzendt. Asynchrone replicatie helpt bij het voorkomen van verhoogde latenties voor schrijfbewerkingen op het primaire cluster.

Continue schrijfbewerkingen, leesbewerkingen op clusterreplica's en verbindingsreeks s

De globale lees-/schrijfbewerkings-verbindingsreeks in Azure Cosmos DB voor MongoDB leidt schrijfbewerkingen consistent naar het actieve cluster met schrijfbewerkingen. Bij het initiëren van een promotie van een replicacluster wordt het replicacluster in regio B overgeschakeld naar de schrijfmodus, terwijl het oorspronkelijke primaire cluster in Regio A overschakelt naar alleen-lezen. Voordat de promotie wordt uitgevoerd, richt de globale lees-/schrijfbewerkings-verbindingsreeks zich op het primaire cluster in regio A en wordt vervolgens bijgewerkt om naar regio B te verwijzen, omdat hierbij schrijfverantwoordelijkheden worden aangenomen. Voor toepassingen die gebruikmaken van de globale lees-/schrijfbewerkingen verbindingsreeks, worden schrijfbewerkingen naadloos voortgezet tijdens het promotieproces, waarbij ononderbroken gegevensstromen worden onderhouden.

Replicaclusters zijn ook beschikbaar voor leesbewerkingen. Het helpt bij het offloaden van intensieve leesbewerkingen van het primaire cluster of het leveren van een verminderde latentie voor leesbewerkingen aan de clients die zich dichter bij de replicatieregio bevinden. Wanneer replicatie tussen regio's is ingeschakeld, kunnen toepassingen het zelf-verbindingsreeks van het replicacluster gebruiken om leesbewerkingen uit de clusterreplica uit te voeren. Het primaire cluster is beschikbaar voor lees- en schrijfbewerkingen met behulp van een eigen zelf-verbindingsreeks.

Schermopname van het cluster verbindingsreeks een Azure Cosmos DB for MongoDB-cluster (vCore) met inbegrip van globale lees-/schrijfbewerkingen verbindingsreeks en zelf-verbindingsreeks.

Wanneer u een replica maakt door replicatie tussen regio's in te schakelen, neemt deze geen netwerkinstellingen over, zoals firewallregels van het primaire cluster. Deze instellingen moeten onafhankelijk worden ingesteld voor de replica. De replica neemt het beheerdersaccount over van het primaire cluster. Gebruikersaccounts moeten worden beheerd op het primaire cluster. U kunt verbinding maken met het primaire cluster en het bijbehorende replicacluster met behulp van dezelfde gebruikersaccounts.

Promotie van replicacluster

Als er een regiostoring optreedt, kunt u herstel na noodgevallen uitvoeren door uw clusterreplica in een andere regio te promoveren om beschikbaar te worden voor schrijfbewerkingen. Tijdens de promotie van replica's worden deze stappen uitgevoerd:

  1. Schrijfbewerkingen op de replica in regio B zijn ingeschakeld naast leesbewerkingen. De voormalige replica wordt een nieuw read-write-cluster.
  2. Het gepromoveerde replicacluster in regio B accepteert schrijfbewerkingen met behulp van de verbindingsreeks en de globale verbindingsreeks voor lezen/schrijven.
  3. Het cluster in regio A is ingesteld op alleen-lezen en behoudt de verbindingsreeks.

Belangrijk

Omdat replicatie asynchroon is, worden sommige gegevens van het cluster in regio A mogelijk niet gerepliceerd naar regio B wanneer de clusterreplica in regio B wordt gepromoveerd. Als dit het geval is, zou promotie resulteren in de niet-gerepliceerde gegevens die niet aanwezig zijn op beide clusters.