Delen via

Hoge beschikbaarheid (betrouwbaarheid) in Azure Cosmos DB for NoSQL

  • Artikel

In dit artikel wordt ondersteuning voor hoge beschikbaarheid (betrouwbaarheid) in Azure CosmosDB voor NoSQL beschreven en worden zowel beschikbaarheidszones behandeld als herstel na noodgevallen in meerdere regio's en bedrijfscontinuïteit.

Zie Aanbevelingen voor tolerantie voor Azure Cosmos DB voor NoSQL voor algemene aanbevelingen voor tolerantie voor Azure Cosmos DB voor NoSQL.

Ondersteuning voor beschikbaarheidszone

Azure-beschikbaarheidszones zijn ten minste drie fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Datacenters binnen elke zone zijn uitgerust met onafhankelijke energie-, koelings- en netwerkinfrastructuur. In het geval van een storing in een lokale zone worden beschikbaarheidszones zodanig ontworpen dat als de ene zone wordt beïnvloed, regionale services, capaciteit en hoge beschikbaarheid worden ondersteund door de resterende twee zones.

Fouten kunnen variëren van software- en hardwarefouten tot gebeurtenissen zoals aardbevingen, overstromingen en brand. Tolerantie voor fouten wordt bereikt met redundantie en logische isolatie van Azure-services. Zie Regio's en beschikbaarheidszones voor meer informatie over beschikbaarheidszones in Azure.

Services met azure-beschikbaarheidszones zijn ontworpen om het juiste niveau van betrouwbaarheid en flexibiliteit te bieden. Ze kunnen op twee manieren worden geconfigureerd. Ze kunnen zone-redundant zijn, met automatische replicatie tussen zones of zonegebonden, waarbij exemplaren zijn vastgemaakt aan een specifieke zone. U kunt deze benaderingen ook combineren. Zie Aanbevelingen voor meer informatie over zone-redundante versus zone-redundante architectuur voor het gebruik van beschikbaarheidszones en regio's.

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

Azure Cosmos DB biedt:

Tolerantie voor uitval van afzonderlijke knooppunten. 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.

Tolerantie voor zonestoring. 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. Zie Hersteldoelstellingen voor meer informatie over RTO.

Als beschikbaarheidszones zijn ingeschakeld, ondersteunt Azure Cosmos DB for NoSQL een zone-redundante configuratie.

Vereisten

Impact van het gebruik van beschikbaarheidszones

De impact van beschikbaarheidszones op de hoge beschikbaarheid van uw Cosmos DB for NoSQL-database is afhankelijk van het consistentieniveau van het account en welke regio's beschikbaarheidszones hebben ingeschakeld. In veel gevallen voegen beschikbaarheidszones geen waarde toe of voegen ze minimale waarde toe als het account meerdere regio's is (tenzij geconfigureerd met sterke consistentie).

Raadpleeg de onderstaande tabel om de impact van het gebruik van beschikbaarheidszones in uw huidige accountconfiguratie te schatten:

Accountconsistentieniveau Regio's waarvoor beschikbaarheidszones zijn ingeschakeld Impact van het gebruik van beschikbaarheidszones
Asynchroon (Gebonden veroudering of zwakker) Een willekeurig aantal secundaire leesregio's. Biedt minimale waarde omdat de SDK al naadloze omleidingen biedt voor leesbewerkingen wanneer een leesregio uitvalt.
Synchroon (sterk) Twee of meer secundaire leesregio's Biedt marginale waarde omdat het systeem dynamische quorum kan gebruiken als een leesregio de beschikbaarheid verliest, waardoor schrijfbewerkingen kunnen worden voortgezet.
Synchroon (sterk) Eén secundair leesgebied Biedt meer waarde omdat het verlies van een leesregio in dit scenario van invloed kan zijn op de beschikbaarheid van schrijfbewerkingen.
Alle Regio's en een willekeurig aantal secundaire regio's schrijven Zorgt voor een grotere beschikbaarheid voor schrijfbewerkingen voor zonegebonden fouten.
Alle Eén regio Eén regio kan niet profiteren van failovermogelijkheden voor meerdere regio's. Het gebruik van beschikbaarheidszones beschermt tegen het totale beschikbaarheidsverlies vanwege zonegebonden fouten.

SLA-verbeteringen

Omdat beschikbaarheidszones fysiek gescheiden zijn en afzonderlijke energiebron, netwerk en koeling bieden, zijn de BESCHIKBAARHEIDS-SLA's (Service level agreements) hoger (99,995%) dan accounts met één regio (99,99%). Regio's waarvoor beschikbaarheidszones zijn ingeschakeld, worden in rekening gebracht tegen 25% premium, terwijl voor regio's zonder beschikbaarheidszones geen premium geldt. Bovendien wordt afgezien van de premium-prijzen voor beschikbaarheidszones voor accounts die zijn geconfigureerd met schrijfbewerkingen in meerdere regio's en/of voor verzamelingen die zijn geconfigureerd met de modus voor automatisch schalen.

Als u een extra regio toevoegt aan een Cosmos DB-account, wordt de bestaande factuur doorgaans met 100% verhoogd (additief niet vermenigvuldigd) hoewel er kleine verschillen in kosten in verschillende regio's bestaan. Zie de pagina met prijzen voor meer informatie.

Het inschakelen van AZ's, het toevoegen van extra regio(s) of het inschakelen van schrijfbewerkingen voor meerdere regio's kan worden beschouwd als een gelaagde benadering die de tolerantie en beschikbaarheid van een bepaald Cosmos DB-account in elke stap verhoogt: van de beschikbaarheid van 4 9 voor één regio zonder AZ-configuratie, tot en met 4 en half 9's voor één regio met AZ's, helemaal tot 5 9's van beschikbaarheid voor configuratie voor meerdere regio's waarvoor schrijfoptie voor meerdere regio's is ingeschakeld. Raadpleeg de volgende tabel voor een overzicht van SLA's voor elke configuratie.

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.

Een resource maken waarvoor beschikbaarheidszones zijn ingeschakeld

U kunt beschikbaarheidszones alleen configureren wanneer u een nieuwe regio toevoegt aan een Azure Cosmos DB NoSQL-account.

Als u ondersteuning voor beschikbaarheidszones wilt inschakelen, kunt u het volgende gebruiken:

Migreren naar ondersteuning voor beschikbaarheidszones

Zie Azure Cosmos DB for NoSQL migreren naar ondersteuning voor beschikbaarheidszones voor meer informatie over het migreren van uw Cosmos DB-account naar ondersteuning voor beschikbaarheidszones.

Herstel na noodgevallen en bedrijfscontinuïteit tussen regio's

Herstel na noodgevallen (DR) gaat over het herstellen van gebeurtenissen met een hoge impact, zoals natuurrampen of mislukte implementaties die downtime en gegevensverlies tot gevolg hebben. 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 voordat u nadenkt over het maken van uw plan voor herstel na noodgevallen.

Als het gaat om herstel na noodgevallen, gebruikt Microsoft het model voor gedeelde verantwoordelijkheid. In een model voor gedeelde verantwoordelijkheid zorgt Microsoft ervoor dat de basisinfrastructuur en platformservices beschikbaar zijn. Tegelijkertijd repliceren veel Azure-services niet automatisch gegevens of vallen ze 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 services die worden uitgevoerd op PaaS-aanbiedingen (Platform as a Service) van Azure bieden functies en richtlijnen ter ondersteuning van herstel na noodgeval en u kunt servicespecifieke functies gebruiken om snel herstel te ondersteunen om uw DR-plan te ontwikkelen.

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:

  • Continue back-ups maken elke 100 seconden een back-up van elke regio. Hiermee kunt u uw gegevens herstellen naar een bepaald tijdstip met granulariteit van 1 seconde. In elke regio is de back-up afhankelijk van de gegevens die in die regio zijn vastgelegd. Als de regio beschikbaarheidszones heeft ingeschakeld, wordt de back-up opgeslagen in zone-redundante opslagaccounts.
  • Periodieke back-ups maken volledig een back-up van alle partities van alle containers onder uw account, zonder synchronisatie tussen partities. Het minimale back-upinterval is 1 uur.

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.

Door service beheerde failover

Als uw oplossing continue uptime vereist tijdens regiostoringen, kunt u Azure Cosmos DB zo configureren dat uw gegevens in meerdere regio's worden gerepliceerd en wanneer dat nodig is, transparant een failover naar operationele regio's uitvoeren.

Accounts met één regio kunnen na een regionale storing de toegankelijkheid verliezen. Om te zorgen voor bedrijfscontinuïteit, 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 bedrijfscontinuïteit 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

  • Het gebruik van een round robin-beleid 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.

Storingen lezen en schrijven

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](.). /cosmos-db/how-to-manage-database-account.yml#perform-manual-failover-on-an-azure-cosmos-db-account. 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).

Detectie, melding en beheer van storingen

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.

Testen op hoge beschikbaarheid

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.

Gerelateerde inhoud