Uppnå hög tillgänglighet med Azure Cosmos DB

  • Artikel

GÄLLER FÖR: Nosql Mongodb Cassandra Gremlin Tabell

För att skapa en lösning med hög tillgänglighet måste du utvärdera tillförlitlighetsegenskaperna för alla dess komponenter. Azure Cosmos DB innehåller funktioner och konfigurationsalternativ som hjälper dig att uppnå hög tillgänglighet för din lösning.

Den här artikeln använder följande termer:

  • Mål för återställningstid (RTO): Tiden mellan början av ett avbrott som påverkar Azure Cosmos DB och återställningen till full tillgänglighet.
  • Mål för återställningspunkt (RPO): Tiden mellan den senaste skrivning som återställdes korrekt och tidpunkten för början av det avbrott som påverkar Azure Cosmos DB.

Kommentar

Förväntade och maximala RRPOs och RTO:er beror på vilken typ av avbrott som Azure Cosmos DB upplever. Ett avbrott i en enskild nod har till exempel en annan förväntad RTO och RPO än avbrott i en hel region.

Den här artikeln beskriver de händelser som kan påverka Azure Cosmos DB-tillgängligheten och motsvarande konfigurationsalternativ för Azure Cosmos DB.

Replikunderhåll

Azure Cosmos DB är en tjänst för flera klienter som hanterar all information om enskilda beräkningsnoder transparent. Användarna behöver inte bekymra sig om någon typ av korrigering eller planerat underhåll. Azure Cosmos DB garanterar serviceavtal för tillgänglighet och P99-svarstid genom alla automatiska underhållsåtgärder som systemet utför.

Replikeringsfel

Replikavbrott är avbrott för enskilda noder i ett Azure Cosmos DB-kluster som distribueras i en Azure-region.

Azure Cosmos DB minimerar automatiskt replikfel genom att garantera minst tre repliker av dina data i varje Azure-region för ditt konto inom ett kvorum med fyra repliker. Den här garantin resulterar i en RTO på 0 och ett RPO på 0 för enskilda nodfel, utan att programändringar eller konfigurationer krävs.

I många Azure-regioner är det möjligt att distribuera ditt Azure Cosmos DB-kluster mellan tillgänglighetszoner. Tillgänglighetszoner kan öka serviceavtalen eftersom de är fysiskt åtskilda och ger en distinkt energikälla, nätverk och kylning. När du distribuerar ett Azure Cosmos DB-konto med hjälp av tillgänglighetszoner tillhandahåller Azure Cosmos DB en RTO på 0 och ett RPO på 0, även i ett zonfel.

När du distribuerar i en enda Azure-region, utan extra användarindata, är Azure Cosmos DB motståndskraftigt mot nodstopp. Om du aktiverar redundans mellan tillgänglighetszoner blir Azure Cosmos DB motståndskraftigt mot zonstopp på bekostnad av ökade avgifter.

Du kan bara konfigurera zonredundans när du lägger till en ny region i ett Azure Cosmos DB-konto. För befintliga regioner kan du aktivera zonredundans genom att ta bort regionen och sedan lägga till den igen med zonredundans aktiverad. För ett konto med en region kräver den här metoden att du lägger till en region som du tillfälligt redundansväxlar till och sedan tar bort och lägger till önskad region med zonredundans aktiverad.

Som standard använder inte ett Azure Cosmos DB-konto flera tillgänglighetszoner. Du kan aktivera distribution över flera tillgänglighetszoner på följande sätt:

Om ditt Azure Cosmos DB-konto distribueras i N Azure-regioner kommer det att finnas N x 4 kopior av alla dina data. Mer information om hur Azure Cosmos DB replikerar data i varje region finns i Global distribution med Azure Cosmos DB. Att ha ett Azure Cosmos DB-konto i mer än två regioner förbättrar programmets tillgänglighet och ger låg svarstid i de associerade regionerna.

Regionstopp

Regionstopp är avbrott som påverkar alla Azure Cosmos DB-noder i en Azure-region i alla tillgänglighetszoner. För sällsynta fall av regionstopp kan du konfigurera Azure Cosmos DB för att stödja olika resultat av hållbarhet och tillgänglighet.

Varaktighet

När ett Azure Cosmos DB-konto distribueras i en enda region sker vanligtvis ingen dataförlust. Dataåtkomsten återställs när Azure Cosmos DB-tjänsterna har återställts i den berörda regionen. Dataförlust kan endast inträffa vid en oåterkallelig katastrof i Azure Cosmos DB-regionen.

Azure Cosmos DB tillhandahåller två säkerhetskopieringslägen för att skydda mot fullständig dataförlust som kan uppstå till följd av katastrofala katastrofer i en region:

När ett Azure Cosmos DB-konto distribueras i flera regioner beror datahållbarheten på den konsekvensnivå som du konfigurerar för kontot. Följande tabell beskriver för alla konsekvensnivåer RPO för ett Azure Cosmos DB-konto som distribueras i minst två regioner.

Konsekvensnivå RPO för regionstopp
Session, konsekvent prefix, slutlig Mindre än 15 minuter
Begränsad föråldring K och T
Stark 0

K = Antalet versioner (d.v.s. uppdateringar) av ett objekt.

T = Tidsintervallet sedan den senaste uppdateringen.

För konton med flera regioner är det lägsta värdet för K och T 100 000 skrivåtgärder eller 300 sekunder. Det här värdet definierar det minsta RPO för data när du använder begränsad föråldring.

Mer information om skillnaderna mellan konsekvensnivåer finns i Konsekvensnivåer i Azure Cosmos DB.

Tillgänglighet

Om lösningen kräver kontinuerlig tillgänglighet under regionstopp kan du konfigurera Azure Cosmos DB för att replikera dina data i flera regioner och transparent redundansväxla till tillgängliga regioner vid behov.

Konton med en region kan förlora tillgängligheten efter ett regionalt avbrott. För att säkerställa hög tillgänglighet hela tiden rekommenderar vi att du konfigurerar ditt Azure Cosmos DB-konto med en enda skrivregion och minst en andra (läs)region och aktiverar tjänsthanterad redundans.

Med tjänsthanterad redundans kan Azure Cosmos DB redundansväxla skrivregionen för ett konto med flera regioner för att bevara tillgängligheten på bekostnad av dataförlust, enligt beskrivningen tidigare i avsnittet Hållbarhet . Regionala redundans identifieras och hanteras i Azure Cosmos DB-klienten. De kräver inga ändringar från programmet. Anvisningar om hur du aktiverar flera läsregioner och tjänsthanterad redundans finns i Hantera ett Azure Cosmos DB-konto med hjälp av Azure-portalen.

Viktigt!

Om du har valt skrivkonfiguration för en region med flera läsregioner rekommenderar vi starkt att du konfigurerar De Azure Cosmos DB-konton som används för produktionsarbetsbelastningar för att aktivera tjänsthanterad redundans. Med den här konfigurationen kan Azure Cosmos DB redundansväxla kontodatabaserna till tillgängliga regioner. I avsaknad av den här konfigurationen kommer kontot att uppleva förlust av skrivtillgänglighet under hela varaktigheten av avbrott i skrivregionen. Manuell redundans lyckas inte på grund av bristande regionanslutning.

Varning

Även med tjänsthanterad redundans aktiverad kan partiellt avbrott kräva manuella åtgärder för Azure Cosmos DB-tjänstteamet. I dessa scenarier kan det ta upp till 1 timme (eller mer) innan redundansväxlingen börjar gälla. För bättre skrivtillgänglighet vid partiella avbrott rekommenderar vi att du aktiverar tillgänglighetszoner utöver tjänsthanterad redundans.

Flera skrivregioner

Du kan konfigurera Azure Cosmos DB för att acceptera skrivningar i flera regioner. Den här konfigurationen är användbar för att minska skrivfördröjningen i geografiskt distribuerade program.

När du konfigurerar ett Azure Cosmos DB-konto för flera skrivregioner stöds inte stark konsekvens och skrivkonflikter kan uppstå. Mer information om hur du löser dessa konflikter finns i Konflikttyper och lösningsprinciper när du använder flera skrivregioner.

Viktigt!

Att uppdatera samma dokument-ID ofta (eller återskapa samma dokument-ID ofta efter TTL eller borttagning) påverkar replikeringsprestanda på grund av ett ökat antal konflikter som genereras i systemet.  

Konfliktlösningsregion

När ett Azure Cosmos DB-konto har konfigurerats med skrivningar med flera regioner fungerar en av regionerna som skiljedomare i skrivkonflikter.

Metodtips för skrivningar i flera regioner

Här följer några metodtips när du skriver till flera regioner.

Håll lokal trafik lokal

När du använder skrivningar med flera regioner bör programmet utfärda läs- och skrivtrafik som kommer från den lokala regionen strikt till den lokala Cosmos DB-regionen. Undvik anrop mellan regioner för optimala prestanda.

Det är viktigt att programmet minimerar konflikter genom att undvika följande antimönster:

  • Skicka samma skrivåtgärd till alla regioner för att öka oddsen för att få en snabb svarstid

  • Slumpmässigt bestämma målregionen för en läs- eller skrivåtgärd per begäran

  • Använda en resursallokeringsprincip för att fastställa målregionen för en läs- eller skrivåtgärd per begäran

Undvik beroende av replikeringsfördröjning

Du kan inte konfigurera skrivkonton med flera regioner för stark konsekvens. Den region som skrivs för att svara direkt efter att Azure Cosmos DB replikerar data lokalt när data replikeras asynkront globalt.

Även om det är ovanligt kan det uppstå en replikeringsfördröjning på en eller några partitioner när du georeplikerar data. Replikeringsfördröjning kan uppstå på grund av en sällsynt blip i nätverkstrafiken eller högre än vanligt antal konfliktlösningsfrekvenser.

Till exempel introducerar en arkitektur där programmet skriver till region A men läser från region B ett beroende av replikeringsfördröjning mellan de två regionerna. Men om programmet läser och skriver till samma region förblir prestanda konstant även i närvaro av replikeringsfördröjning.

Utvärdera sessionskonsekvensanvändning för skrivåtgärder

I sessionskonsekvens använder du sessionstoken för både läs- och skrivåtgärder.

För läsåtgärder skickar Azure Cosmos DB den cachelagrade sessionstoken till servern med en garanti för att ta emot data som motsvarar den angivna (eller en senare) sessionstoken.

För skrivåtgärder skickar Azure Cosmos DB sessionstoken till databasen med en garanti för att bevara data endast om servern har kommit ikapp den angivna sessionstoken. I skrivkonton med en region garanteras alltid att skrivregionen har kommit ikapp sessionstoken. I skrivkonton med flera regioner kanske den region som du skriver till kanske inte har kommit ikapp skrivningar som utfärdats till en annan region. Om klienten skriver till region A med en sessionstoken från region B kommer region A inte att kunna spara data förrän den kommer ikapp ändringar som gjorts i region B.

Det är bäst att endast använda sessionstoken för läsåtgärder och inte för skrivåtgärder när du skickar sessionstoken mellan klientinstanser.

Minimera snabba uppdateringar av samma dokument

Serverns uppdateringar för att lösa eller bekräfta frånvaron av konflikter kan kollidera med skrivningar som utlöses av programmet när samma dokument uppdateras upprepade gånger. Upprepade uppdateringar i snabb följd till samma dokument får högre svarstider under konfliktlösningen.

Även om tillfälliga utbrott i upprepade uppdateringar av samma dokument är oundvikliga kan du överväga att utforska en arkitektur där nya dokument skapas i stället om trafik med stabilt tillstånd ser snabba uppdateringar av samma dokument under en längre period.

Vad du kan förvänta dig under ett regionstopp

Klienter för konton med en region kommer att förlora läs- och skrivtillgänglighet tills tjänsten har återställts.

Konton med flera regioner upplever olika beteenden beroende på följande konfigurationer och avbrottstyper.

Konfiguration Avbrott Tillgänglighetspåverkan Hållbarhetspåverkan Vad du bör göra
Enstaka skrivregion Avbrott i läsregionen Alla klienter omdirigerar automatiskt läsningar till andra regioner. Det finns ingen förlust av läs- eller skrivtillgänglighet för alla konfigurationer. Undantaget är en konfiguration av två regioner med stark konsekvens, vilket förlorar skrivtillgängligheten tills tjänsten återställs. Om du aktiverar tjänsthanterad redundans markerar tjänsten regionen som misslyckad och en redundansväxling sker. Ingen dataförlust. Under driftstoppet kontrollerar du att det finns tillräckligt med etablerade enheter för programbegäran (RU: er) i de återstående regionerna för att stödja lästrafik.

När avbrottet är över justerar du etablerade RU:er efter behov.
Enstaka skrivregion Avbrott i skrivregionen Klienter omdirigerar läsningar till andra regioner.

Utan tjänsthanterad redundans drabbas klienter av förlust av skrivtillgänglighet. Återställning av skrivtillgänglighet sker automatiskt när avbrotten upphör.

Med tjänsthanterad redundans upplever klienter förlust av skrivtillgänglighet tills tjänsten hanterar en redundansväxling till en ny skrivregion som du väljer.		 Om du inte väljer den starka konsekvensnivån kanske tjänsten inte replikerar vissa data till de återstående aktiva regionerna. Den här replikeringen beror på vilken konsekvensnivå du väljer. Om den berörda regionen drabbas av permanent dataförlust kan du förlora otillförlitliga data. Under driftstoppet kontrollerar du att det finns tillräckligt med etablerade RU:er i de återstående regionerna för att stödja lästrafik.

Utlös inte en manuell redundansväxling under driftstoppet eftersom det inte kan lyckas.

När avbrottet är över justerar du etablerade RU:er efter behov. Konton som använder API:et för NoSQL kan också återställa opublicerade data i den misslyckade regionen från ditt konfliktflöde.
Flera skrivregioner Eventuella regionala avbrott Det finns en möjlighet till tillfällig förlust av skrivtillgänglighet, vilket motsvarar en enda skrivregion med tjänsthanterad redundans. Redundansväxlingen i konfliktlösningsregionen kan också orsaka förlust av skrivtillgänglighet om ett stort antal motstridiga skrivningar inträffar vid tidpunkten för avbrottet. Nyligen uppdaterade data i den misslyckade regionen kan vara otillgängliga i de återstående aktiva regionerna, beroende på den valda konsekvensnivån. Om den berörda regionen drabbas av permanent dataförlust kan du förlora otillförlitliga data. Under driftstoppet kontrollerar du att det finns tillräckligt med etablerade RU:er i de återstående regionerna för att stödja mer trafik.

När driftstoppet är över kan du justera etablerade RU:er efter behov. Om möjligt återställer Azure Cosmos DB automatiskt opublicerade data i den misslyckade regionen. Den här automatiska återställningen använder den konfliktlösningsmetod som du konfigurerar för konton som använder API:et för NoSQL. För konton som använder andra API:er använder den här automatiska återställningen senaste skrivvinster.

Ytterligare information om avbrott i läsregionen

  • Den berörda regionen är frånkopplad och markerad offline. Azure Cosmos DB SDK:er omdirigerar läsanrop till nästa tillgängliga region i listan över prioriterade regioner.

  • Om ingen av regionerna i listan över prioriterade regioner är tillgängliga återgår anropen automatiskt till den aktuella skrivregionen.

  • Inga ändringar krävs i programkoden för att hantera avbrott i läsregionen. När den berörda läsregionen är online igen synkroniseras den med den aktuella skrivregionen och är tillgänglig igen för att hantera läsbegäranden när den har kommit ifatt fullständigt.

  • Efterföljande läsningar omdirigeras till den återställda regionen utan att det krävs några ändringar i din programkod. Under både redundansväxling och återkoppling av en tidigare misslyckad region fortsätter Azure Cosmos DB att uppfylla läskonsekvensgarantier.

  • Även i en sällsynt och olycklig händelse där en Azure-skrivregion är permanent oåterkallelig går det inte att förlora några data om ditt Azure Cosmos DB-konto med flera regioner har konfigurerats med stark konsekvens. Ett Azure Cosmos DB-konto med flera regioner har hållbarhetsegenskaperna som angavs tidigare i avsnittet Hållbarhet .

Ytterligare information om avbrott i skrivregionen

  • Under ett avbrott i skrivregionen befordrar Azure Cosmos DB-kontot en sekundär region till den nya primära skrivregionen när tjänsthanterad redundans konfigureras på Azure Cosmos DB-kontot. Redundansväxlingen sker i en annan region i den ordning som du anger regionprioritet.

  • Manuell redundans bör inte utlösas och kommer inte att lyckas i närvaro av ett avbrott i käll- eller målregionen. Anledningen är att redundansproceduren innehåller en konsekvenskontroll som kräver anslutning mellan regionerna.

  • När den tidigare berörda regionen är online igen görs alla skrivdata som inte replikerades när regionen misslyckades tillgängliga via konfliktflödet. Program kan läsa konfliktflödet, lösa konflikterna baserat på den programspecifika logiken och skriva tillbaka uppdaterade data till Azure Cosmos DB-containern efter behov.

  • När den tidigare berörda skrivregionen har återställts visas den som "online" i Azure-portalen och blir tillgänglig som en läsregion. I det här läget är det säkert att växla tillbaka till den återställda regionen som skrivregion med hjälp av PowerShell, Azure CLI eller Azure-portalen. Det finns inga data- eller tillgänglighetsförluster före, medan eller efter du byter skrivregion. Programmet är fortfarande mycket tillgängligt.

Varning

I händelse av ett avbrott i skrivregionen, där Azure Cosmos DB-kontot befordrar en sekundär region till den nya primära skrivregionen via tjänsthanterad redundansväxling, höjs inte den ursprungliga skrivregionen tillbaka som skrivregion automatiskt när den har återställts. Det är ditt ansvar att gå tillbaka till den återställda regionen som skrivregion med hjälp av PowerShell, Azure CLI eller Azure-portalen (när det är säkert att göra det, enligt beskrivningen ovan).

Serviceavtal

I följande tabell sammanfattas funktionerna för hög tillgänglighet i olika kontokonfigurationer.

KPI Skrivningar med en region utan tillgänglighetszoner Skrivningar med en region med tillgänglighetszoner Skrivningar med flera regioner och en region utan tillgänglighetszoner Skrivningar med flera regioner med en region med tillgänglighetszoner Skrivningar med flera regioner, flera regioner med eller utan tillgänglighetszoner
Serviceavtal för skrivtillgänglighet 99,99 % 99.995% 99,99 % 99.995% 99,999 %
SLA för lästillgänglighet 99,99 % 99.995% 99,999 % 99,999 % 99,999 %
Zonfel: dataförlust Dataförluster Ingen dataförlust Ingen dataförlust Ingen dataförlust Ingen dataförlust
Zonfel: tillgänglighet Tillgänglighetsförlust Ingen tillgänglighetsförlust Ingen tillgänglighetsförlust Ingen tillgänglighetsförlust Ingen tillgänglighetsförlust
Regionalt avbrott: dataförlust Dataförluster Dataförluster Beroende på konsekvensnivå. Mer information finns i Konsekvens, tillgänglighet och prestandaavvägningar. Beroende på konsekvensnivå. Mer information finns i Konsekvens, tillgänglighet och prestandaavvägningar. Beroende på konsekvensnivå. Mer information finns i Konsekvens, tillgänglighet och prestandaavvägningar.
Regionalt avbrott: tillgänglighet Tillgänglighetsförlust Tillgänglighetsförlust Ingen tillgänglighetsförlust för läsregionfel, tillfälligt för fel i skrivregionen Ingen tillgänglighetsförlust för läsregionfel, tillfälligt för fel i skrivregionen Ingen förlust av lästillgänglighet, tillfällig förlust av skrivtillgänglighet i den berörda regionen
Pris (1) Inte tillämpligt Etablerad RU/s x 1,25-hastighet Etablerade RU/s x N-regioner Etablerade RU/s x 1,25 rate x N-regioner (2) Skrivfrekvens för flera regioner x N-regioner

1 För serverlösa konton multipliceras RU:er med en faktor på 1,25.

2 1,25-priset gäller endast för regioner där du aktiverar tillgänglighetszoner.

Tips för att skapa program med hög tillgänglighet

  • Granska det förväntade beteendet för Azure Cosmos DB SDK:er under händelser och vilka konfigurationer som påverkar det.

  • För att säkerställa hög skriv- och lästillgänglighet konfigurerar du ditt Azure Cosmos DB-konto så att det omfattar minst två regioner (eller tre, om du använder stark konsekvens). Mer information finns i Självstudie: Konfigurera global distribution i Azure Cosmos DB med hjälp av API:et för NoSQL.

  • För Azure Cosmos DB-konton med flera regioner som har konfigurerats med en enda skrivregion aktiverar du tjänsthanterad redundans med hjälp av Azure CLI eller Azure-portalen. När du har aktiverat tjänsthanterad redundans kommer Azure Cosmos DB att redundansväxla ditt konto utan några användarindata när det uppstår ett regionalt haveri.

  • Även om ditt Azure Cosmos DB-konto är mycket tillgängligt kanske programmet inte är korrekt utformat för att förbli mycket tillgängligt. Om du vill testa programmets höga tillgänglighet från slutpunkt till slutpunkt som en del av dina programtestnings- eller haveriberedskapstest (DR) inaktiverar du tillfälligt tjänsthanterad redundans för kontot. Anropa manuell redundans med hjälp av PowerShell, Azure CLI eller Azure-portalen och övervaka sedan ditt program. När du har slutfört testet kan du redundansväxla till den primära regionen och återställa tjänsthanterad redundans för kontot.

    Viktigt!

    Anropa inte manuell redundans vid ett Azure Cosmos DB-avbrott i antingen käll- eller målregionen. Manuell redundans kräver regionanslutning för att upprätthålla datakonsekvens, så att den inte lyckas.

  • I en globalt distribuerad databasmiljö finns det en direkt relation mellan konsekvensnivån och datahållbarheten i närvaro av ett regionomfattande avbrott. När du utvecklar din affärskontinuitetsplan måste du förstå den maximala godkända tiden innan programmet återställs helt efter en störande händelse (det vill: RTO). Du måste också förstå den maximala perioden för de senaste datauppdateringarna som programmet kan tolerera att förlora när det återställs efter en störande händelse (d.s. RPO). Mer information om RTO och RPO finns i Konsekvensnivåer i Azure Cosmos DB.

Vad du kan förvänta dig under ett avbrott i Azure Cosmos DB-regionen

För konton med en region kan klienter förlora läs- och skrivtillgänglighet under ett avbrott i Azure Cosmos DB-regionen. Konton med flera regioner har olika beteenden, enligt beskrivningen i följande tabell.

Skrivregioner Tjänsthanterad redundans Vad du kan förvänta dig Vad du bör göra
Enstaka skrivregion Inte aktiverad Om det uppstår ett avbrott i en läsregion när du inte använder stark konsekvens omdirigerar alla klienter till andra regioner. Det finns ingen förlust av läs- eller skrivtillgänglighet och inga data går förlorade. När du använder stark konsekvens kan ett avbrott i en läsregion påverka skrivtillgängligheten om färre än två läsregioner finns kvar.

Om det uppstår ett avbrott i skrivregionen drabbas klienterna av förlust av skrivtillgänglighet. Om du inte valde stark konsekvens kanske tjänsten inte replikerar vissa data till de återstående aktiva regionerna. Den här replikeringen beror på den valda konsekvensnivån. Om den berörda regionen drabbas av permanent dataförlust kan du förlora otillförlitliga data.

Azure Cosmos DB återställer skrivtillgängligheten när avbrotten upphör.		 Under driftstoppet kontrollerar du att det finns tillräckligt med etablerade RU:er i de återstående regionerna för att stödja lästrafik.

Utlös inte en manuell redundansväxling under driftstoppet eftersom det inte kan lyckas.

När avbrottet är över justerar du etablerade RU:er efter behov.
Enstaka skrivregion Aktiverat Om det uppstår ett avbrott i en läsregion när du inte använder stark konsekvens omdirigerar alla klienter till andra regioner. Det finns ingen förlust av läs- eller skrivtillgänglighet och inga data går förlorade. När du använder stark konsekvens kan avbrott i en läsregion påverka skrivtillgängligheten om färre än två läsregioner finns kvar.

Om det uppstår ett avbrott i skrivregionen drabbas klienter av förlust av skrivtillgänglighet tills Azure Cosmos DB väljer en ny region som den nya skrivregionen enligt dina inställningar. Om du inte valde stark konsekvens kanske tjänsten inte replikerar vissa data till de återstående aktiva regionerna. Den här replikeringen beror på den valda konsekvensnivån. Om den berörda regionen drabbas av permanent dataförlust kan du förlora otillförlitliga data.		 Under driftstoppet kontrollerar du att det finns tillräckligt med etablerade RU:er i de återstående regionerna för att stödja lästrafik.

Utlös inte en manuell redundansväxling under driftstoppet eftersom det inte kan lyckas.

När avbrottet är över kan du flytta tillbaka skrivregionen till den ursprungliga regionen och justera etablerade RU:er efter behov. Konton som använder API:et för NoSQL kan också återställa opublicerade data i den misslyckade regionen från ditt konfliktflöde.
Flera skrivregioner Inte tillämpligt Nyligen uppdaterade data i den misslyckade regionen kanske inte är tillgängliga i de återstående aktiva regionerna. Eventuella, konsekventa prefix- och sessionskonsekvensnivåer garanterar en inaktuellhet på mindre än 15 minuter. Begränsad föråldring garanterar färre än K-uppdateringar eller T-sekunder , beroende på konfigurationen. Om den berörda regionen drabbas av permanent dataförlust kan du förlora otillförlitliga data. Under driftstoppet kontrollerar du att det finns tillräckligt med etablerade RU:er i de återstående regionerna för att stödja mer trafik.

När driftstoppet är över kan du justera etablerade RU:er efter behov. Om möjligt återställer Azure Cosmos DB opublicerade data i den misslyckade regionen. Den här återställningen använder den konfliktlösningsmetod som du konfigurerar för konton som använder API:et för NoSQL. För konton som använder andra API:er använder den här återställningen senaste skrivvinster.

Nästa steg

Därefter kan du läsa följande artiklar: