Hoge beschikbaarheid bereiken met Azure Cosmos DB

  • Artikel

VAN TOEPASSING OP: Nosql MongoDB Cassandra Gremlin Tabel

Als u een oplossing met hoge beschikbaarheid wilt bouwen, moet u de betrouwbaarheidskenmerken van alle bijbehorende onderdelen evalueren. Azure Cosmos DB biedt functies en configuratieopties om u te helpen bij het bereiken van hoge beschikbaarheid voor uw oplossing.

In dit artikel worden deze volgende termen gebruikt:

  • Beoogde hersteltijd (RTO):de tijd tussen het begin van een storing die van invloed is op Azure Cosmos DB en het herstel naar volledige beschikbaarheid.
  • RPO (Recovery Point Objective): de tijd tussen de laatste schrijfbewerking die correct is hersteld en de tijd van het begin van de storing die van invloed is op Azure Cosmos DB.

Notitie

Verwachte en maximale RPO's en RTO's zijn afhankelijk van het soort storing dat Azure Cosmos DB ondervindt. Een storing van één knooppunt heeft bijvoorbeeld een andere verwachte RTO en RPO dan de storing van een hele regio.

In dit artikel worden de gebeurtenissen beschreven die van invloed kunnen zijn op de beschikbaarheid van Azure Cosmos DB en de bijbehorende azure Cosmos DB-configuratieopties.

Replicaonderhoud

Azure Cosmos DB is een multitenant-service waarmee alle details van afzonderlijke rekenknooppunten transparant worden beheerd. Gebruikers hoeven zich geen zorgen te maken over een soort patching of gepland onderhoud. Azure Cosmos DB garandeert SLA's voor beschikbaarheid en P99-latentie door alle automatische onderhoudsbewerkingen die door het systeem worden uitgevoerd.

Onderbrekingen van replica's

Replicastoringen zijn storingen van afzonderlijke knooppunten in een Azure Cosmos DB-cluster dat is geïmplementeerd in een Azure-regio.

Azure Cosmos DB vermindert automatisch replicastoringen door ten minste drie replica's van uw gegevens in elke Azure-regio te garanderen voor uw account binnen een quorum met vier replica's. Deze garantie resulteert in een RTO van 0 en een RPO van 0 voor afzonderlijke knooppuntstoringen, zonder dat er toepassingswijzigingen of configuraties nodig zijn.

In veel Azure-regio's is het mogelijk om uw Azure Cosmos DB-cluster over beschikbaarheidszones te distribueren. Beschikbaarheidszones kunnen SLA's verhogen omdat ze fysiek gescheiden zijn en een afzonderlijke voedingsbron, netwerk en koeling bieden. Wanneer u een Azure Cosmos DB-account implementeert met behulp van beschikbaarheidszones, biedt Azure Cosmos DB een RTO van 0 en een RPO van 0, zelfs in een zonestoring.

Wanneer u in één Azure-regio implementeert, zonder extra gebruikersinvoer, is Azure Cosmos DB bestand tegen storingen in knooppunten. Door redundantie in meerdere beschikbaarheidszones in te schakelen, is Azure Cosmos DB tolerant voor zonestoringen tegen de kosten van verhoogde kosten.

U kunt zoneredundantie alleen configureren wanneer u een nieuwe regio toevoegt aan een Azure Cosmos DB-account. Voor bestaande regio's kunt u zoneredundantie inschakelen door de regio te verwijderen en deze vervolgens weer toe te voegen met de zoneredundantie ingeschakeld. Voor een account met één regio moet u voor deze benadering een regio toevoegen om tijdelijk een failover naar toe te voegen en vervolgens de gewenste regio te verwijderen en toe te voegen waarvoor zoneredundantie is ingeschakeld.

Standaard gebruikt een Azure Cosmos DB-account niet meerdere beschikbaarheidszones. U kunt implementatie in meerdere beschikbaarheidszones op de volgende manieren inschakelen:

Als uw Azure Cosmos DB-account is verdeeld over N Azure-regio's, zijn er N x 4 kopieën van al uw gegevens. Zie Globale distributie met Azure Cosmos DB voor meer informatie over hoe Azure Cosmos DB gegevens in elke regio repliceert. Als u een Azure Cosmos DB-account in meer dan twee regio's hebt, verbetert u de beschikbaarheid van uw toepassing en zorgt u voor lage latentie in de gekoppelde regio's.

Regiostoringen

Regiostoringen zijn storingen die van invloed zijn op alle Azure Cosmos DB-knooppunten in een Azure-regio, in alle beschikbaarheidszones. Voor zeldzame gevallen van regiostoringen kunt u Azure Cosmos DB configureren ter ondersteuning van verschillende resultaten van duurzaamheid en beschikbaarheid.

Duurzaamheid

Wanneer een Azure Cosmos DB-account in één regio wordt geïmplementeerd, treedt er doorgaans geen gegevensverlies op. Gegevenstoegang wordt hersteld nadat Azure Cosmos DB-services zijn hersteld in de betreffende regio. Gegevensverlies kan alleen optreden met een onherstelbare ramp in de Azure Cosmos DB-regio.

Azure Cosmos DB biedt twee back-upmodi om u te beschermen tegen volledig gegevensverlies dat kan leiden tot catastrofale rampen in een regio:

Wanneer een Azure Cosmos DB-account in meerdere regio's wordt geïmplementeerd, is duurzaamheid van gegevens afhankelijk van het consistentieniveau dat u voor het account configureert. De volgende tabeldetails, voor alle consistentieniveaus, de RPO van een Azure Cosmos DB-account dat in ten minste twee regio's is geïmplementeerd.

Consistentieniveau RPO voor regiostoring
Sessie, consistent voorvoegsel, uiteindelijk Minder dan 15 minuten
Gebonden veroudering K en T
Sterk 0

K = Het aantal versies (dat wil gezegd, updates) van een item.

T = Het tijdsinterval sinds de laatste update.

Voor accounts met meerdere regio's is de minimale waarde van K en T 100.000 schrijfbewerkingen of 300 seconden. Deze waarde definieert de minimale RPO voor gegevens wanneer u gebonden veroudering gebruikt.

Zie Consistentieniveaus in Azure Cosmos DB voor meer informatie over de verschillen tussen consistentieniveaus.

Beschikbaarheid

Als uw oplossing continue beschikbaarheid vereist tijdens regiostoringen, kunt u Azure Cosmos DB configureren om uw gegevens over meerdere regio's te repliceren en een transparante failover naar beschikbare regio's uit te voeren wanneer dat nodig is.

Accounts met één regio verliezen mogelijk de beschikbaarheid na een regionale storing. Om te allen tijde hoge beschikbaarheid te garanderen, raden we u aan uw Azure Cosmos DB-account in te stellen met één schrijfregio en ten minste een tweede (lees)regio en servicebeheerde failover in te schakelen.

Met service beheerde failover kan azure Cosmos DB een failover uitvoeren voor de schrijfregio van een account met meerdere regio's om de beschikbaarheid te behouden ten koste van gegevensverlies, zoals eerder beschreven in de sectie Duurzaamheid . Regionale failovers worden gedetecteerd en verwerkt in de Azure Cosmos DB-client. Er zijn geen wijzigingen van de toepassing vereist. Zie Een Azure Cosmos DB-account beheren met behulp van Azure Portal voor instructies over het inschakelen van meerdere leesregio's en door de service beheerde failover.

Belangrijk

Als u een schrijfconfiguratie met één regio met meerdere leesregio's hebt gekozen, raden we u ten zeerste aan de Azure Cosmos DB-accounts te configureren die worden gebruikt voor productieworkloads om door de service beheerde failover mogelijk te maken. Met deze configuratie kan azure Cosmos DB een failover uitvoeren voor de accountdatabases naar beschikbare regio's. Bij afwezigheid van deze configuratie ondervindt het account verlies van schrijf beschikbaarheid voor de hele duur van de storing in de schrijfregio. Handmatige failover slaagt niet vanwege een gebrek aan regioconnectiviteit.

Waarschuwing

Zelfs als service-beheerde failover is ingeschakeld, kan een gedeeltelijke storing handmatige tussenkomst vereisen voor het Azure Cosmos DB-serviceteam. In deze scenario's kan het tot 1 uur (of langer) duren voordat de failover van kracht wordt. Voor een betere beschikbaarheid van schrijfbewerkingen tijdens gedeeltelijke storingen raden we u aan om naast door de service beheerde failover beschikbaarheidszones in te schakelen.

Meerdere schrijfregio's

U kunt Azure Cosmos DB zo configureren dat schrijfbewerkingen in meerdere regio's worden geaccepteerd. Deze configuratie is handig voor het verminderen van de schrijflatentie in geografisch gedistribueerde toepassingen.

Wanneer u een Azure Cosmos DB-account configureert voor meerdere schrijfregio's, wordt sterke consistentie niet ondersteund en kunnen er schrijfconflicten optreden. Zie Conflicttypen en oplossingsbeleid bij het gebruik van meerdere schrijfregio's voor meer informatie over het oplossen van deze conflicten.

Belangrijk

Het regelmatig bijwerken van dezelfde document-id (of het opnieuw maken van dezelfde document-id na TTL of verwijderen) heeft invloed op de replicatieprestaties vanwege een verhoogd aantal conflicten dat in het systeem is gegenereerd.  

Regio voor conflictoplossing

Wanneer een Azure Cosmos DB-account is geconfigureerd met schrijfbewerkingen met meerdere regio's, fungeert een van de regio's als een arbiter in schrijfconflicten.

Aanbevolen procedures voor schrijfbewerkingen in meerdere regio's

Hier volgen enkele aanbevolen procedures om rekening mee te houden wanneer u naar meerdere regio's schrijft.

Lokaal verkeer lokaal houden

Wanneer u schrijfbewerkingen met meerdere regio's gebruikt, moet de toepassing lees- en schrijfverkeer uitgeven dat afkomstig is uit de lokale regio, strikt naar de lokale Cosmos DB-regio. Vermijd gesprekken tussen regio's voor optimale prestaties.

Het is belangrijk dat de toepassing conflicten minimaliseert door de volgende antipatronen te voorkomen:

  • Dezelfde schrijfbewerking naar alle regio's verzenden om de kans op een snelle reactietijd te vergroten

  • Willekeurig bepalen van de doelregio voor een lees- of schrijfbewerking per aanvraag

  • Een round robin-beleid gebruiken om de doelregio te bepalen voor een lees- of schrijfbewerking per aanvraag

Afhankelijkheid van replicatievertraging voorkomen

U kunt schrijfaccounts met meerdere regio's niet configureren voor sterke consistentie. De regio die wordt geschreven om onmiddellijk te reageren nadat Azure Cosmos DB de gegevens lokaal repliceert terwijl de gegevens asynchroon worden gerepliceerd.

Hoewel het niet vaak is, kan er een replicatievertraging optreden op een of een paar partities wanneer u gegevens geo-repliceert. Replicatievertraging kan optreden vanwege een zeldzame blip in netwerkverkeer of een hogere dan gebruikelijke conflictoplossing.

Een architectuur waarin de toepassing bijvoorbeeld naar regio A schrijft, maar leest uit regio B, introduceert een afhankelijkheid van replicatievertraging tussen de twee regio's. Als de toepassing echter leest en schrijft naar dezelfde regio, blijven de prestaties constant, zelfs in aanwezigheid van replicatievertraging.

Sessieconsistentiegebruik evalueren voor schrijfbewerkingen

In sessieconsistentie gebruikt u het sessietoken voor zowel lees- als schrijfbewerkingen.

Voor leesbewerkingen verzendt Azure Cosmos DB het sessietoken in de cache naar de server met een garantie voor het ontvangen van gegevens die overeenkomen met het opgegeven (of een recentere) sessietoken.

Voor schrijfbewerkingen verzendt Azure Cosmos DB het sessietoken naar de database met een garantie dat de gegevens alleen worden bewaard als de server het opgegeven sessietoken heeft bijgehouden. In schrijfaccounts met één regio is de schrijfregio altijd gegarandeerd in het sessietoken opgenomen. In schrijfaccounts voor meerdere regio's is de regio waarnaar u schrijft echter mogelijk niet opgepikt voor schrijfbewerkingen die zijn uitgegeven aan een andere regio. Als de client schrijft naar Regio A met een sessietoken van regio B, kan Regio A de gegevens pas behouden als deze wijzigingen in regio B inhalen.

U kunt het beste sessietokens alleen gebruiken voor leesbewerkingen en niet voor schrijfbewerkingen wanneer u sessietokens doorgeeft tussen clientexemplaren.

Snelle updates voor hetzelfde document beperken

De updates van de server om het ontbreken van conflicten op te lossen of te bevestigen, kunnen botsen met schrijfbewerkingen die door de toepassing worden geactiveerd wanneer hetzelfde document herhaaldelijk wordt bijgewerkt. Herhaalde updates in snel opvolgende volgorde van hetzelfde document ervaren hogere latenties tijdens conflictoplossing.

Hoewel incidentele bursts in herhaalde updates van hetzelfde document onvermijdelijk zijn, kunt u overwegen om een architectuur te verkennen waarin nieuwe documenten worden gemaakt als verkeer met een stabiele status gedurende een langere periode snelle updates voor hetzelfde document ziet.

Wat u kunt verwachten tijdens een storing in een regio

Clients van accounts met één regio ondervinden verlies van lees- en schrijfbeschikbaarheid totdat de service is hersteld.

Accounts met meerdere regio's hebben verschillende gedragingen, afhankelijk van de volgende configuraties en storingstypen.

Configuratie Uitval Invloed op beschikbaarheid Impact op duurzaamheid Wat u moet doen
Regio voor één schrijfbewerking Storing in regio lezen Alle clients leiden leesbewerkingen automatisch om naar andere regio's. Er is geen lees- of schrijftijdverlies voor alle configuraties. De uitzondering is een configuratie van twee regio's met een sterke consistentie, die schrijf beschikbaarheid verliest totdat de service wordt hersteld. Als u door de service beheerde failover inschakelt, markeert de service de regio als mislukt en treedt er een failover op. Geen gegevensverlies. Zorg er tijdens de storing voor dat er voldoende ingerichte aanvraageenheden (RU's) zijn in de resterende regio's om leesverkeer te ondersteunen.

Wanneer de storing voorbij is, worden de ingerichte RU's naar wens aangepast.
Regio voor één schrijfbewerking Onderbreking van regio schrijven Clients leiden leesbewerkingen om naar andere regio's.

Zonder door de service beheerde failover ervaren clients verlies van schrijfbeschikbaarheid. Herstel van de beschikbaarheid van schrijfbewerkingen vindt automatisch plaats wanneer de storing eindigt.

Met door de service beheerde failover ervaren clients verlies van beschikbaarheid totdat de service een failover beheert naar een nieuwe schrijfregio die u selecteert.		 Als u niet het sterke consistentieniveau selecteert, worden sommige gegevens mogelijk niet gerepliceerd naar de resterende actieve regio's. Deze replicatie is afhankelijk van het consistentieniveau dat u selecteert. Als de getroffen regio permanent gegevensverlies ondervindt, kunt u niet-gerepliceerde gegevens verliezen. Zorg er tijdens de storing voor dat er voldoende ingerichte RU's zijn in de resterende regio's ter ondersteuning van leesverkeer.

Activeer geen handmatige failover tijdens de storing, omdat deze niet kan slagen.

Wanneer de storing voorbij is, worden de ingerichte RU's naar wens aangepast. Accounts die gebruikmaken van de API voor NoSQL kunnen ook de niet-gerepliceerde gegevens in de mislukte regio herstellen vanuit uw conflictfeed.
Meerdere schrijfregio's Elke regionale storing Er is een mogelijkheid van tijdelijk verlies van schrijfbeschikbaarheid, wat vergelijkbaar is met één schrijfregio met door de service beheerde failover. De failover van de regio voor conflictoplossing kan ook leiden tot verlies van schrijfbeschikbaarheid als er een groot aantal conflicterende schrijfbewerkingen optreedt op het moment van de storing. Onlangs bijgewerkte gegevens in de mislukte regio zijn mogelijk niet beschikbaar in de resterende actieve regio's, afhankelijk van het geselecteerde consistentieniveau. Als de getroffen regio permanent gegevensverlies ondervindt, verliest u mogelijk niet-gerepliceerde gegevens. Zorg er tijdens de storing voor dat er voldoende ingerichte RU's zijn in de resterende regio's om meer verkeer te ondersteunen.

Wanneer de storing voorbij is, kunt u eventueel ingerichte RU's opnieuw inrichten. Indien mogelijk herstelt Azure Cosmos DB automatisch niet-gerepliceerde gegevens in de mislukte regio. Dit automatische herstel maakt gebruik van de methode voor conflictoplossing die u configureert voor accounts die gebruikmaken van de API voor NoSQL. Voor accounts die andere API's gebruiken, worden voor dit automatische herstel de laatste schrijfwinsten gebruikt.

Aanvullende informatie over storingen in leesregio's

  • De verbinding met de betrokken regio is verbroken en offline gemarkeerd. De Azure Cosmos DB SDK's leiden leesoproepen om naar de volgende beschikbare regio in de lijst met voorkeursregio's .

  • Als geen van de regio's in de lijst met voorkeursregio's beschikbaar is, vallen aanroepen automatisch terug naar de huidige schrijfregio.

  • Er zijn geen wijzigingen vereist in uw toepassingscode om storingen in leesregio's af te handelen. Wanneer de betrokken leesregio weer online is, wordt deze gesynchroniseerd met de huidige schrijfregio en is deze weer beschikbaar om leesaanvragen te verwerken nadat deze volledig is opgepikt.

  • Latere leesbewerkingen worden omgeleid naar de herstelde regio zonder dat er wijzigingen in uw toepassingscode nodig zijn. Tijdens zowel failover als opnieuw deelnemen aan een eerder mislukte regio, blijft Azure Cosmos DB rekening met de garanties voor leesconsistentie.

  • Zelfs in een zeldzame en ongelukkige gebeurtenis waarbij een Azure-schrijfregio permanent onherstelbaar is, is er geen gegevensverlies als uw Azure Cosmos DB-account met meerdere regio's is geconfigureerd met een sterke consistentie. Een Azure Cosmos DB-account met meerdere regio's heeft de duurzaamheidskenmerken die eerder zijn opgegeven in de sectie Duurzaamheid .

Aanvullende informatie over storingen in schrijfregio's

  • Tijdens een storing in een schrijfregio bevordert het Azure Cosmos DB-account een secundaire regio als de nieuwe primaire schrijfregio wanneer een door de service beheerde failover is geconfigureerd op het Azure Cosmos DB-account. De failover treedt op in een andere regio in de volgorde van de regioprioriteit die u opgeeft.

  • Handmatige failover mag niet worden geactiveerd en slaagt niet in de aanwezigheid van een storing in de bron- of doelregio. De reden hiervoor is dat de failoverprocedure een consistentiecontrole bevat waarvoor connectiviteit tussen de regio's is vereist.

  • Wanneer de eerder getroffen regio weer online is, worden schrijfgegevens die niet zijn gerepliceerd wanneer de regio is mislukt, beschikbaar gemaakt via de conflictfeed. Toepassingen kunnen de conflictfeed lezen, de conflicten oplossen op basis van de toepassingsspecifieke logica en de bijgewerkte gegevens zo nodig terugschrijven naar de Azure Cosmos DB-container.

  • Nadat de eerder getroffen schrijfregio is hersteld, wordt deze weergegeven als 'online' in Azure Portal en wordt deze beschikbaar als een leesregio. Op dit moment is het veilig om terug te keren naar de herstelde regio als de schrijfregio met behulp van PowerShell, de Azure CLI of Azure Portal. Er zijn geen gegevens of beschikbaarheidsverlies voor, terwijl of nadat u de schrijfregio hebt overgeschakeld. Uw toepassing blijft maximaal beschikbaar.

Waarschuwing

In het geval van een storing in een schrijfregio, waarbij het Azure Cosmos DB-account een secundaire regio bevordert als de nieuwe primaire schrijfregio via een door de service beheerde failover, wordt de oorspronkelijke schrijfregio niet teruggezet omdat de schrijfregio automatisch wordt gepromoveerd zodra deze is hersteld. Het is uw verantwoordelijkheid om terug te keren naar de herstelde regio als de schrijfregio met behulp van PowerShell, de Azure CLI of Azure Portal (zodra u dit veilig kunt doen, zoals hierboven beschreven).

SLA's

De volgende tabel bevat een overzicht van de mogelijkheden voor hoge beschikbaarheid van verschillende accountconfiguraties.

KPI Schrijfbewerkingen met één regio zonder beschikbaarheidszones Schrijfbewerkingen met één regio met beschikbaarheidszones Schrijfbewerkingen met één regio zonder beschikbaarheidszones Schrijfbewerkingen voor meerdere regio's met beschikbaarheidszones Schrijfbewerkingen in meerdere regio's met of zonder beschikbaarheidszones
SLA voor schrijf beschikbaarheid 99,99% 99.995% 99,99% 99.995% 99,999%
SLA voor lees beschikbaarheid 99,99% 99.995% 99,999% 99,999% 99,999%
Zonefouten: gegevensverlies Gegevensverlies Geen gegevensverlies Geen gegevensverlies Geen gegevensverlies Geen gegevensverlies
Zonefouten: beschikbaarheid Beschikbaarheidsverlies Geen beschikbaarheidsverlies Geen beschikbaarheidsverlies Geen beschikbaarheidsverlies Geen beschikbaarheidsverlies
Regionale storing: gegevensverlies Gegevensverlies Gegevensverlies Afhankelijk van consistentieniveau. Zie Consistentie, beschikbaarheid en prestatieproblemen voor meer informatie. Afhankelijk van consistentieniveau. Zie Consistentie, beschikbaarheid en prestatieproblemen voor meer informatie. Afhankelijk van consistentieniveau. Zie Consistentie, beschikbaarheid en prestatieproblemen voor meer informatie.
Regionale storing: beschikbaarheid Beschikbaarheidsverlies Beschikbaarheidsverlies Geen beschikbaarheidsverlies voor storing in leesregio, tijdelijk voor fout in schrijfregio Geen beschikbaarheidsverlies voor storing in leesregio, tijdelijk voor fout in schrijfregio Geen verlies van lees beschikbaarheid, tijdelijk verlies van schrijf beschikbaarheid in de betrokken regio
Prijs (1) Niet van toepassing Ingerichte RU/s x 1,25-snelheid Ingerichte RU/s x N-regio's Ingerichte RU/s x 1,25 rate x N-regio's (2) Schrijfsnelheid voor meerdere regio's x N-regio's

1 Voor serverloze accounts worden RU's vermenigvuldigd met een factor van 1,25.

2 De snelheid van 1,25 geldt alleen voor regio's waarin u beschikbaarheidszones inschakelt.

Tips voor het bouwen van maximaal beschikbare toepassingen

  • Bekijk het verwachte gedrag van de Azure Cosmos DB SDK's tijdens gebeurtenissen en welke configuraties dit beïnvloeden.

  • Als u een hoge beschikbaarheid van schrijf- en leesbewerkingen wilt garanderen, configureert u uw Azure Cosmos DB-account voor ten minste twee regio's (of drie, als u sterke consistentie gebruikt). Zie zelfstudie: Globale distributie van Azure Cosmos DB instellen met behulp van de API voor NoSQL voor meer informatie.

  • Voor Azure Cosmos DB-accounts met meerdere regio's die zijn geconfigureerd met één schrijfregio, schakelt u servicebeheerde failover in met behulp van de Azure CLI of Azure Portal. Nadat u servicebeheerde failover hebt ingeschakeld, zal Azure Cosmos DB, wanneer er een regionale noodgeval is, een failover van uw account uitvoeren zonder gebruikersinvoer.

  • Zelfs als uw Azure Cosmos DB-account maximaal beschikbaar is, is uw toepassing mogelijk niet correct ontworpen om maximaal beschikbaar te blijven. Als u de end-to-end hoge beschikbaarheid van uw toepassing wilt testen als onderdeel van noodherstelanalyses of noodherstelanalyses, schakelt u servicebeheerde failover tijdelijk uit voor het account. Roep handmatige failover aan met behulp van PowerShell, de Azure CLI of Azure Portal en bewaak vervolgens uw toepassing. Nadat u de test hebt voltooid, kunt u een failover uitvoeren naar de primaire regio en een failover herstellen die door de service wordt beheerd voor het account.

    Belangrijk

    Roep geen handmatige failover aan tijdens een Azure Cosmos DB-storing in de bron- of doelregio. Voor handmatige failover is regioconnectiviteit vereist om gegevensconsistentie te behouden, zodat deze niet lukt.

  • Binnen een wereldwijd gedistribueerde databaseomgeving is er een directe relatie tussen het consistentieniveau en de duurzaamheid van gegevens in de aanwezigheid van een storing in de hele regio. Wanneer u uw bedrijfscontinuïteitsplan ontwikkelt, moet u de maximaal acceptabele tijd begrijpen voordat de toepassing volledig herstelt na een verstorende gebeurtenis (dat wil gezegd de RTO). U moet ook inzicht krijgen in de maximale periode van recente gegevensupdates die de toepassing kan tolereren wanneer deze wordt hersteld na een verstorende gebeurtenis (dat wil gezegd de RPO). Zie Consistentieniveaus in Azure Cosmos DB voor meer informatie over RTO en RPO.

Wat u kunt verwachten tijdens een storing in een Azure Cosmos DB-regio

Voor accounts met één regio ondervinden clients verlies van lees- en schrijfbeschikbaarheid tijdens een storing in een Azure Cosmos DB-regio. Accounts met meerdere regio's hebben verschillende gedragingen, zoals beschreven in de volgende tabel.

Regio's schrijven Door de service beheerde failover Wat u kunt verwachten Wat u moet doen
Regio voor één schrijfbewerking Niet ingeschakeld Als er sprake is van een storing in een leesregio wanneer u geen sterke consistentie gebruikt, worden alle clients omgeleid naar andere regio's. Er is geen verlies van lees- of schrijf beschikbaarheid en er is geen gegevensverlies. Wanneer u sterke consistentie gebruikt, kan een storing in een leesregio van invloed zijn op de beschikbaarheid van schrijfbewerkingen als er minder dan twee leesregio's blijven.

Als er sprake is van een storing in de schrijfregio, ondervinden clients verlies van schrijf beschikbaarheid. Als u geen sterke consistentie hebt geselecteerd, worden sommige gegevens mogelijk niet gerepliceerd naar de resterende actieve regio's. Deze replicatie is afhankelijk van het geselecteerde consistentieniveau. Als de getroffen regio permanent gegevensverlies ondervindt, verliest u mogelijk niet-gerepliceerde gegevens.

Azure Cosmos DB herstelt de beschikbaarheid van schrijfbewerkingen wanneer de storing afloopt.		 Zorg er tijdens de storing voor dat er voldoende ingerichte RU's zijn in de resterende regio's ter ondersteuning van leesverkeer.

Activeer geen handmatige failover tijdens de storing, omdat deze niet kan slagen.

Wanneer de storing voorbij is, worden de ingerichte RU's naar wens aangepast.
Regio voor één schrijfbewerking Ingeschakeld Als er sprake is van een storing in een leesregio wanneer u geen sterke consistentie gebruikt, worden alle clients omgeleid naar andere regio's. Er is geen verlies van lees- of schrijf beschikbaarheid en er is geen gegevensverlies. Wanneer u sterke consistentie gebruikt, kan de onderbreking van een leesregio van invloed zijn op de beschikbaarheid van schrijfbewerkingen als er minder dan twee leesregio's blijven.

Als er sprake is van een storing in de schrijfregio, ondervinden clients verlies van schrijf beschikbaarheid totdat Azure Cosmos DB een nieuwe regio kiest als de nieuwe schrijfregio op basis van uw voorkeuren. Als u geen sterke consistentie hebt geselecteerd, worden sommige gegevens mogelijk niet gerepliceerd naar de resterende actieve regio's. Deze replicatie is afhankelijk van het geselecteerde consistentieniveau. Als de getroffen regio permanent gegevensverlies ondervindt, verliest u mogelijk niet-gerepliceerde gegevens.		 Zorg er tijdens de storing voor dat er voldoende ingerichte RU's zijn in de resterende regio's ter ondersteuning van leesverkeer.

Activeer geen handmatige failover tijdens de storing, omdat deze niet kan slagen.

Wanneer de storing voorbij is, kunt u de schrijfregio terug verplaatsen naar de oorspronkelijke regio en zo nodig ingerichte RU's opnieuw inrichten. Accounts die gebruikmaken van de API voor NoSQL kunnen ook de niet-gerepliceerde gegevens in de mislukte regio herstellen vanuit uw conflictfeed.
Meerdere schrijfregio's Niet van toepassing Onlangs bijgewerkte gegevens in de mislukte regio zijn mogelijk niet beschikbaar in de resterende actieve regio's. Uiteindelijke, consistente voorvoegsel- en sessieconsistentieniveaus garanderen een veroudering van minder dan 15 minuten. Gebonden veroudering garandeert minder dan K-updates of T-seconden , afhankelijk van de configuratie. Als de getroffen regio permanent gegevensverlies ondervindt, verliest u mogelijk niet-gerepliceerde gegevens. Zorg er tijdens de storing voor dat er voldoende ingerichte RU's zijn in de resterende regio's om meer verkeer te ondersteunen.

Wanneer de storing voorbij is, kunt u eventueel ingerichte RU's opnieuw inrichten. Indien mogelijk herstelt Azure Cosmos DB niet-gerepliceerde gegevens in de mislukte regio. Voor dit herstel wordt de conflictoplossingsmethode gebruikt die u configureert voor accounts die gebruikmaken van de API voor NoSQL. Voor accounts die andere API's gebruiken, worden voor dit herstel de laatste schrijfwinsten gebruikt.

Volgende stappen

Vervolgens kunt u de volgende artikelen lezen: