Tillförlitlighet i Azure Cosmos DB

Azure Cosmos DB för NoSQL är en globalt distribuerad databastjänst med flera modeller som stöder dokumentdatamodeller med flexibla scheman. Azure Cosmos DB erbjuder omfattande tillförlitlighetsfunktioner, inklusive flera konsekvensnivåer som gör att du kan balansera prestanda och tillgänglighet, zonredundanta distributioner som skyddar mot fel i tillgänglighetszonen, replikering i flera regioner med tjänsthanterad eller kundhanterad redundans samt alternativ för kontinuerlig och regelbunden säkerhetskopiering för dataskydd.

När du använder Azure är tillförlitlighet ett delat ansvar. Microsoft tillhandahåller en rad funktioner för att stödja återhämtning och återställning. Du ansvarar för att förstå hur dessa funktioner fungerar inom alla tjänster som du använder och välja de funktioner du behöver för att uppfylla dina affärsmål och drifttidsmål.

Den här artikeln beskriver hur du gör Azure Cosmos DB motståndskraftiga mot olika potentiella avbrott och problem, inklusive tillfälliga fel, avbrott i tillgänglighetszonen, regionstopp och serviceunderhåll. Den beskriver också hur du använder säkerhetskopior för att återställa från andra typer av problem och visar viktig information om Azure Cosmos DB serviceavtal (SLA).

Rekommendationer för produktionsdistribution

Azure Well-Architected Framework ger rekommendationer om tillförlitlighet, säkerhet, kostnad, åtgärder och prestanda. Information om hur dessa områden påverkar varandra och bidrar till en tillförlitlig Azure Cosmos DB lösning finns i Architecture best practices for Azure Cosmos DB.

Översikt över tillförlitlighetsarkitektur

I det här avsnittet beskrivs några av de viktiga aspekterna av hur tjänsten fungerar som är mest relevant ur ett tillförlitlighetsperspektiv. I avsnittet beskrivs den logiska arkitekturen, som innehåller några av de resurser och funktioner som du distribuerar och använder. Den diskuterar också den fysiska arkitekturen, som innehåller information om hur tjänsten fungerar under täcket.

Logisk arkitektur

Den primära resursen som du distribuerar är ett Azure Cosmos DB konto. Varje konto kan ha flera databaser med flera containrar. Containrar fungerar som logiska enheter för distribution och skalbarhet. Du kan skapa containrar som samlingar, tabeller och grafer, beroende på vilket API du använder för att interagera med Azure Cosmos DB. Mer information om resursmodellen finns i Databaser, containrar och objekt i Azure Cosmos DB. Varje container använder partitionering, som stöder hög skala och höga prestanda.

Du konfigurerar dataflödet, som representerar mängden systemresurser som du kan använda för att fråga och arbeta med dina data. Du kan etablera dataflöde manuellt, använda autoskalning för att dynamiskt justera kapaciteten baserat på arbetsbelastningens krav eller använda den serverlösa kontotypen för att debiteras för din faktiska användning.

Ett enda konto kan omfatta flera Azure-regioner, vilket ökar din motståndskraft mot regionala avbrott. Du kan konfigurera flera regioner för läsning, och om du använder nivån Affärskritisk kan du använda flera regioner för att skriva. Azure Cosmos DB automatiskt geo-replikerar dina data. Geo-replikeringsbeteendet påverkas av den konfiguration som du använder, till exempel konsekvensnivån, som anger hur du vill göra kompromisser mellan datakonsekvens, tillgänglighet, svarstid och dataflöde. Olika konsekvensnivåer optimerar för olika problem, stöder olika garantier och tillhandahåller olika typer av replikering mellan regioner.

Fysisk arkitektur

Azure Cosmos DB lagrar flera replicas av dina data för redundans. Tjänsten minimerar automatiskt replikfel genom att upprätthålla kvorum mellan repliker i varje region. Den här metoden garanterar hög tillgänglighet och skyddar mot dataförlust vid enskilda nodfel, utan att kräva programändringar eller konfiguration.

Internt hanterar Azure Cosmos DB dina data via olika konstruktioner, inklusive fysiska partitioner, partitionsuppsättningar och replica-uppsättningar. Mer detaljerad information om hur Azure Cosmos DB fungerar finns i Global datadistribution med Azure Cosmos DB – under huven.

Motståndskraft mot tillfälliga fel

Tillfälliga fel är kortvariga, intermittenta fel i komponenter. De förekommer ofta i en distribuerad miljö som molnet, och de är en normal del av åtgärderna. Tillfälliga fel korrigerar sig själva efter en kort tidsperiod. Det är viktigt att dina program kan hantera tillfälliga fel, vanligtvis genom att försöka igen.

Alla molnbaserade program bör följa vägledningen för tillfälliga felhantering i Azure när de kommunicerar med molnbaserade API:er, databaser och andra komponenter. Mer information finns i Rekommendationer för hantering av tillfälliga fel.

Vi rekommenderar att du använder Azure Cosmos DB SDK:er. SDK:erna implementerar automatiskt stöd för en rad återhämtningsöverväganden, inklusive tillfällig felhantering via automatiska återförsök och uppfyllande av hastighetsbegränsningssvar som skickas av tjänsten. Mer information finns i Design motståndskraftiga program med Azure Cosmos DB SDK:er.

När du arbetar med ett konto för flera regioner stöder SDK också en tröskelbaserad tillgänglighetsstrategi, även kallad säkring, där den skickar parallella läsbegäranden till flera regioner och accepterar det snabbaste svaret. Den här metoden kan förbättra programprestanda när en region tillfälligt får högre svarstid än vanligt.

Motståndskraft mot fel i tillgänglighetszonen

Tillgänglighetszoner är fysiskt separata grupper av datacenter i en Azure-region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.

Azure Cosmos DB stöder zonredundans. När du aktiverar zonredundans distribuerar Azure replikerna av dina data över flera tillgänglighetszoner, vilket ger återhämtning till datacenterproblem och avbrott. Microsoft väljer de tillgänglighetszoner som ska användas.

Diagram som visar ett Azure Cosmos DB konto med en replikuppsättning som innehåller tre repliker som är fördelade över tre separata tillgänglighetszoner.

Ett Azure Cosmos DB konto kan använda flera regioner (platser) för global distribution, skalning och redundans. Du konfigurerar zonredundans separat för varje region i ditt konto.

Att använda zonredundans i Azure Cosmos DB har ingen märkbar inverkan på prestanda eller svarstid. Det kräver inga justeringar i det valda konsekvensläget och kräver ingen ändring av programkoden.

Vi rekommenderar att du använder zonredundans i regioner där den stöds, särskilt för konton med en region. Eftersom tillgänglighetszoner är fysiskt åtskilda och ger distinkta energikällor, nätverk och kylning är tillgänglighets-SERVICEavtalen för Azure Cosmos DB högre för zonredundanta konton än konton som inte använder tillgänglighetszoner.

Tip

Att aktivera zonredundans är ett bra sätt att öka motståndskraften i din Azure Cosmos DB databas utan att införa ytterligare programkomplexiteter eller påverka prestanda. Beroende på din kontokonfiguration kanske det inte ens medför ytterligare kostnader.

Om du inte aktiverar zonredundans är kontot icke-zonindelat i den regionen. Konton som inte är zonbaserade kan placera repliker i en enda tillgänglig zon, vilket kan leda till möjlig nedtid om den specifika zonen drabbas av problem.

Requirements

  • Region support: Du kan aktivera zonredundans i Azure regioner som stöder tillgänglighetszoner. Om du vill se om din region stöder tillgänglighetszoner kan du läsa listan över regioner som stöds.

    Zonredundans är inte en kontoomfattande inställning. Azure Cosmos DB konton kan omfatta flera regioner och varje region kan konfigureras separat för att använda tillgänglighetszoner. Regioner som inte stöder tillgänglighetszoner hindrar dig inte från att aktivera zonredundans i andra regioner inom samma konto.

  • Serverlösa konton: Du kan bara konfigurera zonredundanta serverlösa konton när du skapar dem. Du kan inte konvertera befintliga serverlösa konton utan tillgänglighetszoner till en konfiguration av tillgänglighetszoner. För verksamhetskritiska arbetsbelastningar rekommenderar vi att du använder tilldelad kapacitet.

Överväganden

  • Flera samtidiga zonavbrott: En regionkonto med zonredundans kan upprätthålla läs- och skrivbarhet när ett avbrott påverkar en enskild tillgänglighetszon. Men om avbrottet påverkar flera tillgänglighetszoner eller hela regionen förlorar konton med en region läs- och skrivåtkomst tills tjänsten har återställts. Överväg att distribuera ett konto för flera regioner om du behöver vara motståndskraftig mot att flera zoner misslyckas samtidigt.

  • Konton i flera regioner: Om du har ett konto för flera regioner kan du aktivera zonredundans för alla eller alla kontoregioner som stöder tillgänglighetszoner. Vi rekommenderar starkt att du aktiverar zonredundans när ditt konto är konfigurerat för att använda en enda region, eller om det är konfigurerat att använda en enda skrivregion med flera läsregioner.

Cost

Regioner där zonredundans är aktiverat debiteras med en premium. Premiumpriser för tillgänglighetszoner undantas dock för konton som har konfigurerats med skrivningar i flera regioner och för samlingar som har konfigurerats för att använda autoskalning av dataflödesläge. Mer information finns i Priser för Azure Cosmos DB.

Konfigurera stöd för tillgänglighetszoner

För de flesta konton aktiverar du endast zonredundans när du lägger till en ny region i ett Azure Cosmos DB konto. Om du vill aktivera stöd för tillgänglighetszoner för ett befintligt konto lägger du till en region och aktiverar zonredundans på det. Du kan följa en process för att lägga till en tillfällig region så att du kan konfigurera zonredundans i den ursprungliga regionen. För detaljerade steg, se Aktivera zonredundans på ett Azure Cosmos DB-konto.

För serverlösa konton måste du aktivera zonredundans när du skapar kontot.

Beteende när alla zoner är felfria

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar ett Azure Cosmos DB konto för zonredundans och alla zoner är i drift.

  • Cross-zone operation: Azure Cosmos DB dirigerar automatiskt begäranden till repliker mellan tillgänglighetszoner, så att alla repliker kan hantera en begäran.

  • Datareplikering mellan zoner: När en klient gör en ändring i alla data tillämpas den ändringen på flera repliker i olika zoner för att uppnå kvorum. Den här metoden kallas synkron replikering. Synkron replikering säkerställer en hög nivå av datakonsekvens, vilket minskar sannolikheten för dataförlust vid ett zonfel. Tillgänglighetszoner ligger relativt nära varandra, vilket innebär att svarstiden eller dataflödet påverkas minimalt.

Beteende vid ett zonfel

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar ett Azure Cosmos DB konto för zonredundans och det uppstår ett avbrott i någon av zonerna.

  • Detektering och respons: Azure Cosmos DB-plattformen ansvarar för att upptäcka ett fel i en tillgänglighetszon. Du behöver inte göra något för att påbörja en zone-failover.
  • Notification: Microsoft meddelar dig inte automatiskt när en zon är nere. Du kan dock använda Azure Resource Health för att övervaka hälsotillståndet för en enskild resurs, och du kan konfigurera Resource Health-aviseringar för att meddela dig om problem. Du kan också använda Azure Service Health för att förstå tjänstens övergripande hälsotillstånd, inklusive eventuella zonfel, och du kan konfigurera Service Health-aviseringar för att meddela dig om problem.

  • Aktiva begäranden: När en tillgänglighetszon blir otillgänglig avslutar Azure Cosmos DB pågående begäranden som är anslutna till repliker i den berörda zonen och programmet måste försöka igen. Se till att programmet förbereds genom att följa vägledningen för tillfällig felhantering.

  • Förväntad dataförlust: Det finns ingen förväntad dataförlust från ett zonfel.

  • Förväntad stilleståndstid: Under zonavbrott kan anslutningar uppleva korta avbrott som vanligtvis varar några sekunder när trafiken omfördelas. Se till att dina program förbereds genom att följa vägledningen för tillfällig felhantering.

  • Redistribution: Azure Cosmos DB omdirigerar automatiskt inkommande begäranden till felfria repliker i andra tillgänglighetszoner. När en tillgänglighetszon har ett avbrott omallokerar plattformen automatiskt etablerat dataflöde till andra repliker.

Zonåterställning

När tillgänglighetszonen återställs återställer Azure Cosmos DB automatiskt repliker i tillgänglighetszonen och omdirigerar trafik mellan repliker som vanligt.

Test för zonfel

Redundansväxling och återställning av tillgänglighetszoner för Azure Cosmos DB hanteras helt av Microsoft. Du behöver inte initiera eller validera processer för fel i tillgänglighetszoner.

Motståndskraft mot regionomfattande fel

När du distribuerar ett Azure Cosmos DB konto i en enda region orsakar ett regionomfattande avbrott som påverkar alla Azure Cosmos DB noder vanligtvis inte dataförlust, men det hindrar ditt program från att komma åt data. Azure Cosmos DB återställer dataåtkomsten när tjänsten har återställts i den berörda regionen. Dataförlust uppstår endast om regionen upplever en oåterkallelig katastrof.

För att förbereda dig för sällsynta fall av regionfel kan du konfigurera Azure Cosmos DB för att stödja olika nivåer av hållbarhet och tillgänglighet med någon av följande metoder:

I följande tabell sammanfattas de återställningsalternativ som är tillgängliga baserat på kontokonfigurationen och typen av avbrott. Senare avsnitt i den här artikeln innehåller omfattande information om dessa alternativ och tillhörande beteende.

Configuration Typ av avbrott Tillgänglighetspåverkan Hållbarhetspåverkan Vad du ska göra
Konto för en region Regionavbrott Läs- och skrivåtkomst går förlorad tills tjänsten har återställts. Ingen dataförlust om inte regionen upplever en oåterkallelig katastrof. Vänta tills tjänsten återställs eller begär att kontot återställs från säkerhetskopian till en annan region.
Konto för en enda skrivregion, flera regioner Avbrott i läsregionen SDK omdirigeras till tillgängliga regioner baserat på önskad regionskonfiguration.

För konton som använder stark konsekvens med endast två regioner, eller begränsad inaktuellhet som överskrider föråldringsfönstret, går även skrivtillgängligheten förlorad om du inte tar den berörda regionen offline.		 Ingen dataförlust. Se till att det finns tillräckligt med dataflöde i återstående regioner. För stark eller begränsad föråldringskonsekvens bör du överväga att ta den berörda regionen offline.
Konto för en enda skrivregion, flera regioner Avbrott i skrivområdet (med PPAF aktiverat) Automatisk övergång på partitionsnivå; utan behov av manuell åtgärd. Om kontot använder sig av stark överensstämmelse kommer ingen data att gå förlorad. Om kontot inte använder stark konsekvens kan oreplikerade data gå förlorade om regionen drabbas av den osannolika händelsen att permanent dataförlust inträffar. Ingen åtgärd krävs. PPAF hanterar redundans automatiskt.
Konto för en enda skrivregion, flera regioner Avbrott i skrivregionen (utan PPAF) Skrivtillgängligheten går förlorad tills en region offlineåtgärd eller tjänsthanterad redundans har slutförts. Läsningen fortsätter från friska regioner. Om kontot använder stark konsistens, förloras ingen data. Om kontot inte använder stark konsistens kan oreplicerad data gå förlorad i den osannolika händelse att regionen drabbas av permanent dataförlust. Utför en offline-åtgärd för regionen. Om tjänsthanterad redundans är aktiverad initierar Azure Cosmos DB redundans automatiskt, men det kan ta en timme eller mer. Ändra inte skrivregionen under driftstoppet.
Konto med flera skrivarregioner Eventuella regionstopp Automatisk routning till felfria regioner via SDK-konfiguration; inga manuella åtgärder krävs. Nyligen uppdaterade data i den misslyckade regionen kan vara otillgängliga i återstående regioner. Om regionen osannolikt skulle drabbas av permanent dataförlust kan oreplicerad data gå förlorad. Se till att det finns tillräckligt med dataflöde i återstående regioner. Efter återställningen återställer Azure Cosmos DB automatiskt oreplikerade data med hjälp av den konfigurerade konfliktlösningsmetoden.
Alla kontokonfigurationer Skadade data eller oavsiktlig borttagning Ingen tillgänglighetspåverkan. Potentiell dataförlust beroende på när skada eller borttagning identifieras. Återställning vid en specifik tidpunkt (kontinuerlig säkerhetskopiering) eller återställning från periodisk säkerhetskopiering.

Note

Den här artikeln fokuserar på tillförlitlighetsaspekterna för funktionerna i flera regioner i Azure Cosmos DB. Det finns andra fördelar med flera läs- och skrivregioner, till exempel högre prestanda och skalning för globalt distribuerade program. Du bör utvärdera hela lösningsarkitekturen och överväga alla fördelar med att använda dessa funktioner.

SDK:er och återhämtning

De Azure Cosmos DB SDK:erna är en viktig del av programmets återhämtningsstrategi. När du har ett konto för flera regioner påverkar SDK-konfigurationen hur begäranden dirigeras mellan regioner, inklusive önskade regioner att ansluta till och regioner som ska undantas. SDK:er övervakar tillgängligheten för regioner och partitioner och kan dynamiskt konfigurera om sig själva för att använda felfria regioner och partitioner, till exempel via kretsbrytaren på partitionsnivå.

Mer information om hur SDK stöder hög tillgänglighet finns i dokumentationen om hög tillgänglighet för det SDK som du använder:

Potentiell dataförlust vid regionstopp

När du distribuerar ett Azure Cosmos DB konto i flera regioner beror datahållbarheten på den konsekvensnivå som du konfigurerar för kontot. I följande tabell beskrivs för alla konsekvensnivåer mål för återställningspunkt (RPO) för ett Azure Cosmos DB konto som distribueras i minst två regioner. RPO står för den potentiella dataförlusten vid avbrott i en region.

Konsekvensnivå RPO för regionavbrott
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 minsta RPO för data när du använder begränsad fördröjning.

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

Flera läsregioner med en enda skrivregion

Om lösningen kräver kontinuerlig drifttid under regionavbrott kan du konfigurera Azure Cosmos DB för att replikera dina data i flera regioner, med skrivningar som hanteras av din primära region. Du kan också konfigurera dina program för att ansluta till specifika läsregioner, vilket kan bidra till att förbättra deras prestanda. Om en region har ett avbrott kan kontot fortsätta att fungera från felfria regioner.

Diagram som visar ett Azure Cosmos DB konto. Region A är en skriv- och läsregion och region B är en läsregion. Ett program i region A utför läsningar och skrivningar mot Azure Cosmos DB-kontot i region A. Ett program i region B utför läsningar mot kontot i region B, men skriver mot region A. Internt replikerar Azure Cosmos DB ändringar mellan regions.

Automatisk övergång mellan regioner

Du kan konfigurera Azure Cosmos DB SDK med en prioriterad lista över läsregioner. SDK:et ansluter ditt program till den första tillgängliga regionen i listan. Under ett avbrott i läsregionen identifierar SDK:n regionstoppet via svarskoder för serverdelen, markerar det som otillgängligt och dirigerar framtida åtgärder till nästa tillgängliga region i inställningslistan. Se till att listan med önskade regioner är korrekt inställd och att den överensstämmer med dina krav på affärs- och svarstid. Detaljerad vägledning finns i Felsöka Tillgänglighet för Azure Cosmos DB SDK.

Omkoppling är processen att göra en av regionerna i ditt konto otillgänglig, antingen helt eller delvis. Effekten av en övergång beror på om regionen är en skrivregion eller en läsregion:

  • Om en skrivregion blir otillgänglig blir en annan region den nya skrivregionen.
  • Om en läsregion blir otillgänglig kan den regionen inte hantera läsbegäranden och andra regioner används i stället för läsåtgärder.

Azure Cosmos DB innehåller flera typer av redundans:

  • Per-partition automatisk redundans (PPAF): Internt sprider Azure Cosmos DB dina data över flera fysiska partitioner. Om ett problem uppstår med infrastrukturen som stöder en partition påverkas kanske inte andra partitioner. Med PPAF kan konton som endast har en skrivregion automatiskt växla över enskilda partitioner till en sekundär region, medan friska partitioner behålls i den primära regionen. PPAF kan bidra till att minimera stilleståndstiden och möjliggöra snabbare återställning under ett partiellt regionfel. Mer information finns i How to onboard and adopt Per-Partition Automatic Failover (PPAF) for Azure Cosmos DB.

    Note

    Automatisk redundansväxling per partition finns i offentlig förhandsversion. Den här funktionen tillhandahålls utan ett serviceavtal. Mer information finns i Kompletterande villkor för användning av Microsoft Azure-förhandsversioner.

  • Tvingad failover: Du kan ta en av ditt kontos regioner offline. Detta kallas även för en kundhanterad failover eller en offline-regionåtgärd. Det här är den rekommenderade metoden för att snabbt återställa tillgängligheten under ett avbrott. Du ansvarar för att identifiera avbrott och utlösa redundansväxlingen. Du kan också använda tvingade failovers för att simulera scenarier med nedstängd region för testning, till exempel under en katastrofåterställningsövning.

    Om du kopplar från skrivregionen blir läsregionen med näst högsta prioritet den nya skrivregionen. Om du tar en läsregion offline kan dina program ansluta till alla andra läsregioner i kontot.

    En tvingad omställning av din skrivregion medför risken för dataförlust för ej replikerade skrivningar.

    Efter en tvingad failover måste Microsoft återställa regionen online. För felfria regioner automatiseras den här processen men kan ta upp till flera dagar. Om regionen inte är online igen inom en dag eller två öppnar du ett supportärende för att begära hjälp.

  • Ändra skrivregion: När regionerna är felfria kan du ändra ditt kontos skrivregion. Den här ändringen är i själva verket en planerad redundansväxling av skrivregionen för ditt konto.

    Om du ändrar skrivregionen blir det ingen dataförlust eftersom datareplikeringen kommer ikapp innan den nya skrivregionen höjs upp. Det kan uppstå ett kort avbrott, men klienter som använder omprövningslogik och andra tillfälliga felhanteringstekniker får vanligtvis inte någon större inverkan.

    Den här åtgärden kräver att regionerna är felfria, så den kan inte användas under ett regionsavbrott.

  • Servicehanterad redundansväxling: När ditt konto använder tjänsthanterad redundans är Microsoft ansvarig för att bestämma när redundansväxlingen ska utföras mellan regioner. Om du vill aktivera tjänsthanterad redundans anger du prioriteter för varje region. Processen med att deklarera ett avbrott och utlösa tjänsthanterad redundans kan dock ta lång tid – potentiellt en timme eller mer. Utför en tvingad redundansväxling i stället för att vänta på att tjänsthanterad redundansväxling ska utlösas för snabbare återställning.

    Om Microsoft utlöser tjänsthanterad omkoppling för kontots skrivregion kan eventuella oreplikerade skrivningar gå förlorade.

    Efter en tjänstehanterad redundansväxling måste Microsoft återställa en region online. Microsoft för regionen online automatiskt, men den här processen kan ta flera dagar.

Requirements

Region support: Du kan konfigurera alla Azure regioner som en läsregion för ditt Azure Cosmos DB-konto.

Cost

Om du lägger till ytterligare en läsregion i ett Azure Cosmos DB konto ökar dina befintliga kostnader för varje region. Mer information finns i Priser för Azure Cosmos DB.

Konfigurera flera läsregioner

Kapacitetsplanering och -hantering

Om ditt program sprider begäranden mellan regioner och en region går offline, får de återstående regionerna högre volym för begäranden. Använd autoskalningsdataflöde för att dynamiskt justera kapaciteten baserat på efterfrågan. Om du använder tilldelad genomströmning, planera för tillräcklig kapacitet för att hantera förlusten av en region utan försämring av tjänsten och överväg överallokering. Mer information finns i Hantera kapacitet med överetablering.

Beteende när alla regioner är felfria

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar ett Azure Cosmos DB-konto med flera läsregioner och alla regioner är i drift.

  • Åtgärd mellan regioner: Ditt program konfigurerar den region som ska ta emot läsåtgärder. Du kan konfigurera ditt program med en prioriterad lista över regioner eller exkludera vissa regioner. Mer information om hur val av region fungerar finns i Diagnose och felsök tillgängligheten för Azure Cosmos DB SDK:er i multiregionala miljöer.

    Alla skrivåtgärder dirigeras till ditt kontos skrivregion.

  • Datareplikering mellan regioner: Alla skrivåtgärder sker i ditt kontos primära region. Skrivningar replikeras till de andra läsregionerna baserat på kontots konfigurerade konsekvensnivå. Information om den maximala replikeringsfördröjningen finns i Potentiell dataförlust vid regionstopp.

Beteende vid ett läsområdesfel

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar ett Azure Cosmos DB-konto med flera läsregioner och det uppstår ett avbrott i någon av kontots läsregioner.

Important

Helst bör avbrott i läsregioner hanteras på klientnivå genom att korrekt konfigurera listan över prioriterade regioner i SDK-konfigurationen. När SDK:et har konfigurerats korrekt identifierar det automatiskt avbrott och omdirigerar läsåtgärder till nästa tillgängliga region utan att kräva någon redundans på tjänstsidan.

  • Identifiering och svar: Ansvaret för att identifiera avbrott och svara beror på vilken typ av redundans ditt konto använder.

    • PPAF: PPAF gäller vanligtvis inte för avbrott i läsregionen. Men för konton med stark konsekvens och endast två regioner minskar förlusten av läsregionen kontot till en enda region, vilket inte kan upprätthålla dynamiskt kvorum. I det här scenariot kan PPAF aktiveras för att bevara tillgängligheten genom att flytta de berörda partitionerna till den felfria regionen.

    • Tvingad omkoppling: Du ansvarar för att utföra en tvingad omkoppling. För detaljerade steg, se Utför tvingad failover för ditt Azure Cosmos DB-konto.

      Om du inte utför en redundansväxling beror beteendet för ditt konto på dess konsekvensnivå:

      • Stark konsekvens: Stark konsekvens kräver två eller flera regioner för att upprätthålla dynamiskt kvorum. Om det finns färre än två tillgängliga regioner och du inte utför en redundansväxling förlorar kontot skrivtillgängligheten tills tjänsten återställs.

      • Begränsad fördröjningskonsekvens: Begränsad fördröjningskonsekvens bygger på att upprätthålla en specifik fördröjningsgräns mellan regioner. Om längden på regionstopp överskrider tröskelvärdet kan systemet inte upprätthålla samstämmighet mellan skrivningar. Om du inte utför en omkoppling, förlorar kontot möjligheten att skriva tills tjänsten har återställts.

    • Servicehanterad redundansväxling: Om tjänsthanterad redundans är aktiverad identifierar Microsoft så småningom avbrottet och initierar en redundansväxling av ditt konto. Den här processen kan dock ta lång tid, eventuellt en timme eller mer. Utför en tvingad redundansväxling i stället för att vänta på att tjänsthanterad redundansväxling ska utlösas för snabbare återställning.

  • Notification: Microsoft meddelar dig inte automatiskt när en region är nere. Observera följande:

  • Aktiva begäranden: Alla aktiva begäranden kan avslutas och måste försökas igen av klienten när redundansväxlingen har slutförts. Om klienterna hanterar tillfälliga fel på rätt sätt genom att försöka igen efter en kort tidsperiod undviker de vanligtvis betydande påverkan.

  • Förväntad dataförlust: Ett avbrott i en läsregion orsakar inte dataförlust. Azure Cosmos DB fortsätter att uppfylla läskonsekvensgarantier.

  • Förväntad stilleståndstid: Hur lång stilleståndstid ditt konto har beror på vilken typ av redundans ditt konto använder.

    • PPAF: När PPAF är aktiverat identifierar och återställer systemet automatiskt från felet, vanligtvis inom 3 minuter, utan manuella åtgärder.

    • Tvingad redundansväxling: Stilleståndstid beror på:

      • Hur lång tid det tar att identifiera driftstoppet och initiera en redundansväxling.

      • Hur lång tid redundansväxlingen tar, vilket vanligtvis är några sekunder.

        Varning

        Utför inga konfigurationsåtgärder (kontrollplan) i den berörda regionen under avbrottsscenarier, eftersom de resulterar i inkonsekvens i kontot och fördröjer återställningen. Några exempel på kontrollplanåtgärder som ska undvikas är:

        • Ändra skrivregion eller ändra redundansprioritet
        • Uppdatera kontot till konfiguration för flera skrivningar
        • Uppdatera konsekvensinställningar eller andra kontoinställningar
        • Uppdatera privata slutpunktskonfigurationer eller nätverksinställningar
        • Uppdatera kontodataflöde eller skalningsåtgärder
        • Andra åtgärder som ändrar kontokonfigurationen eller regioninställningarna

    • Tjänsthanterad redundansväxling: Microsoft ansvarar för att initiera den tjänsthanterade redundansväxlingen, och den stilleståndstid som ditt konto upplever baseras på den tid det tar för Microsoft att deklarera avbrottet och påbörja redundansväxlingen. I vissa situationer kan det ta en timme eller mer. Om ditt konto upplever avbrott i skrivprocesser och du snabbt behöver återställa skrivtillgängligheten, utför du en tvingad överflyttning.

  • Omfördelning: För tvingad redundans eller tjänsthanterad redundans kopplas den berörda regionen från och markeras som offline.

    Inga ändringar krävs i programkoden för att hantera avbrott i läsregionen. Azure Cosmos DB SDK:er omdirigera läsåtgärder 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 läsåtgärder automatiskt till kontots aktuella skrivregion enligt konfigurationen i tjänsten.

    Note

    Om du använder privata slutpunkter med ett Azure Cosmos DB konto kontrollerar du att den privata DNS:en dirigeras korrekt efter offline-regionåtgärden. Detaljerad vägledning finns i Redundansöverväganden för privata slutpunkter.

Beteende vid fel i skrivregionen

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar ett Azure Cosmos DB konto med flera läsregioner och det uppstår ett avbrott i kontots skrivregion.

  • Identifiering och svar: Ansvaret för att identifiera avbrott och svara beror på vilken typ av redundans ditt konto använder.

    • PPAF: Microsoft identifierar automatiskt avbrott och initierar en redundansväxling av vissa partitioner, om det är lämpligt. Din applikation behöver inte vidta några åtgärder.

    • Tvingad redundansväxling: Du ansvarar för att utföra en tvingad redundansväxling. Detaljerade steg finns i Utför tvingad överflyttning för ditt Azure Cosmos DB-konto.

      Om du inte utför en omkoppling förlorar kontot möjligheten att skriva tills tjänsten återställs.

      Om det uppstår ett avbrott i skrivregionen för ditt konto bör du undvika att utföra en åtgärd för att ändra skrivregion. Ändringar i skrivregionen lyckas inte om det uppstår ett avbrott i käll- eller målregionen. Anledningen är att regionändringsproceduren innehåller en konsekvenskontroll som kräver anslutning mellan regionerna.

    • Tjänsthanterad redundansväxling: Microsoft identifierar automatiskt avbrott och initierar en redundansväxling av ditt konto. Din applikation behöver inte vidta några åtgärder.

  • Notification: Microsoft meddelar dig inte automatiskt när en region är nere. Observera följande:

  • Aktiva begäranden: Alla aktiva begäranden kan avslutas och måste försökas igen av klienten när redundansväxlingen har slutförts. Om klienterna hanterar tillfälliga fel på rätt sätt genom att försöka igen efter en kort tidsperiod undviker de vanligtvis betydande påverkan.

  • Förväntad dataförlust: Om du konfigurerar ditt konto med stark konsekvens sker ingen dataförlust. Annars kan eventuella icke-replikerade skrivningar gå förlorade efter att överlåtelsen har slutförts. Information om den maximala dataförlust som förväntas under ett regionstopp finns i Potentiell dataförlust vid regionstopp.

  • Förväntad stilleståndstid: Hur lång stilleståndstid ditt konto har beror på vilken typ av redundans ditt konto använder.

    • PPAF: När PPAF är aktiverat förväntar du dig ett kort avbrott, vilket vanligtvis är cirka 3 minuter.

    • Tvingad redundansväxling: Stilleståndstid beror på:

      • Hur lång tid det tar att identifiera driftstoppet och initiera en redundansväxling.
      • Hur lång tid redundansväxlingen tar, vilket vanligtvis är några sekunder.

    Varning

    Utför inga kontrollplansåtgärder i den berörda regionen under avbrottsscenarier, eftersom de resulterar i inkonsekvens i kontot och fördröjer återställningen. Några exempel på kontrollplanåtgärder som ska undvikas är:

    • Ändra skrivregion eller ändra redundansprioritet
    • Uppdatera kontot till konfiguration för flera skrivningar
    • Uppdatera konsekvensinställningar eller andra kontoinställningar
    • Uppdatera privata slutpunktskonfigurationer eller nätverksinställningar
    • Uppdatera kontodataflöde eller skalningsåtgärder
    • Andra åtgärder som ändrar kontokonfigurationen eller regioninställningarna
    • Servicehanterad redundansväxling: Microsoft ansvarar för att initiera servicehanterad redundansväxling, och den stilleståndstid ditt konto upplever beror på hur lång tid det tar för Microsoft att konstatera avbrottet och initiera redundansväxling. I vissa situationer kan det ta en timme eller mer. Utför en tvingad redundansväxling för att snabbt återställa skrivtillgängligheten.

  • Omfördelning: Omdistribution av skrivtrafik beror på vilken typ av redundans ditt konto använder.

    • PPAF: Azure Cosmos DB växlar automatiskt över den icke-fungerande partitionen till en fungerande region.

    • Tvingad redundansväxling: När du utför en tvingad redundansväxling ändras skrivregionen för ditt konto till den region som du anger.

    Note

    Om du använder privata slutpunkter med ett Azure Cosmos DB konto kontrollerar du att den privata DNS:en dirigeras korrekt efter offline-regionåtgärden. Detaljerad vägledning finns i Redundansöverväganden för privata slutpunkter.

    • Tjänsthanterad failöver: Azure Cosmos DB befordrar automatiskt en av kontots sekundära regioner till att bli den nya primära skrivregionen. Överflyttningen sker till en annan region enligt den prioritet du angett för regioner.

Regionåterställning

Microsoft måste föra tillbaka en region online. När en region återställs efter ett avbrott, sätter Microsoft automatiskt regionen online. Den här processen kan dock ta flera dagar.

Important

Efter en tvingad redundansväxling ansluter Microsoft automatiskt regionen igen för felfria regioner. Om regionen inte är online igen inom en dag eller två öppnar du ett supportärende för att begära hjälp.

När regionen är online skiljer sig de åtgärder du vidtar beroende på om avbrottet var i en läsregion eller en skrivregion.

  • Efter avbrott i läsregionen: När den berörda regionen ä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 omkoppling och återanslutning av en tidigare misslyckad region fortsätter Azure Cosmos DB att uppfylla läskonsekvensgarantier.

  • Efter avbrott i skrivregionen: När den berörda regionen är online igen visas regionen som "online" i Azure-portalen och blir tillgänglig som en läsregion. Nu är det säkert att ändra tillbaka skrivregionen till den återställda regionen.

    Important

    Den återställda regionen befordras inte tillbaka som skrivregion automatiskt när den har återställts. Det är ditt ansvar att gå tillbaka till den återställda regionen som skrivregion när det är säkert att göra det.

    Det finns inga data- eller tillgänglighetsförluster före, medan eller efter att du har ändrat skrivregionen. Din applikation fortsätter att vara mycket tillgänglig.

    Om några skrivningar inte replikerades innan regionen gick offline kan du läsa de orelikerade skrivningar från konfliktflödet. Ditt program kan läsa konfliktflödet, lösa eventuella konflikter baserat på programspecifik logik och skriva tillbaka uppdaterade data till containern efter behov.

Test för regionfel

Ditt program kanske inte hanterar områdetilldelningar korrekt, även om ditt Azure Cosmos DB-konto har hög tillgänglighet. 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 forced failover med hjälp av PowerShell, Azure CLI eller Azure-portalen och övervaka sedan ditt program. När du har slutfört testet kan du växla tillbaka till den primära regionen när regionen kommer online automatiskt och sedan återställa tjänsthanterad failover för kontot. Om regionen inte är online igen inom en dag eller två öppnar du ett supportärende för att begära hjälp.

Om ditt konto använder PPAF kan du simulera en partitionsredundans. Mer information finns i Testa PPAF-konfigurationen (simulera fel).

Flera skrivregioner

Du kan konfigurera Azure Cosmos DB för att acceptera skrivningar i flera regioner. Den här konfigurationen kan ge mycket hög motståndskraft mot avbrott i regionen. Det är också användbart för att minska skrivfördröjningen i geografiskt distribuerade program.

Diagram som visar ett Azure Cosmos DB konto. Region A och region B är båda skriv- och läsregioner. Ett program i region A utför läsningar och skrivningar mot Azure Cosmos DB-kontot i region A. Ett program i region B utför läsningar och skrivningar mot Azure Cosmos DB-kontot i region B. Internt replikerar Azure Cosmos DB asynkront ändringar mellan regions.

När du konfigurerar ett Azure Cosmos DB-konto för flera skrivregioner, kan sterk konsistens inte garanteras och skrivkonflikter kan uppstå. Navområdet fungerar som en medlare i skrivkonflikter. Mer information om hur du löser dessa konflikter finns i Konflikttyper och lösningsprinciper när du använder flera skrivregioner.

Det är viktigt att tänka på programmets design och hur det fungerar med flera skrivregioner. Granska metodtipsen för skrivningar i flera regioner.

Requirements

Region support: Du kan konfigurera alla Azure regioner som en läs- eller skrivregion för ditt Azure Cosmos DB-konto.

Cost

Om du lägger till ytterligare en skrivregion i ett Azure Cosmos DB konto ökar dina befintliga kostnader för varje region. Mer information finns i Priser för Azure Cosmos DB.

Konfigurera flera skrivregioner

Du kan konfigurera flera skrivregioner för ditt konto när du skapar kontot eller när som helst efter att kontot har skapats. Mer information finns i Konfigurera flera skrivregioner.

För att effektivt använda flera skrivregioner måste din app också konfigureras på rätt sätt. Se Konfigurera skrivningar i flera regioner i program som använder Azure Cosmos DB.

Kapacitetsplanering och -hantering

Om ditt program sprider begäranden mellan regioner och en region går offline, får de återstående regionerna högre volym för begäranden. Använd autoskala genomströmning för att dynamiskt justera kapaciteten baserat på efterfrågan. Om du använder etablerat genomflöde, planera för tillräcklig kapacitet för att hantera förlusten av en region utan tjänstförsämring och överväga överprovisionering. Mer information finns i Hantera kapacitet med överetablering.

Beteende när alla regioner är felfria

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar ett Azure Cosmos DB konto med flera skrivregioner och alla regioner är i drift.

Beteende under ett regionfel

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar ett Azure Cosmos DB-konto med flera skrivregioner och det uppstår ett avbrott i någon av kontots läs- eller skrivregioner.

  • Identifiering och svar: Ditt program identifierar förlusten av regionen. Azure Cosmos DB SDK:er tillhandahåller funktioner för automatisk regionval som dirigerar läs- och skrivåtgärder till felfria regioner.

  • Notification: Microsoft meddelar dig inte automatiskt när en region är nere. Observera följande:

  • Aktiva begäranden: Alla aktiva begäranden kan avslutas och måste försökas igen av klienten när redundansväxlingen har slutförts. Om klienterna hanterar tillfälliga fel på rätt sätt genom att försöka igen efter en kort tidsperiod undviker de vanligtvis betydande påverkan.

  • Förväntad dataförlust: Nyligen uppdaterade data kan bli otillgängliga i andra regioner. Information om den maximala dataförlust som förväntas under ett regionstopp finns i Potentiell dataförlust vid regionstopp. I det osannolika fallet att den berörda regionen drabbas av permanent dataförlust kan du förlora oreplikerad data.

  • Förväntad stilleståndstid: Det finns ingen förväntad stilleståndstid i konfigurationer med flera skrivningar, förutsatt att SDK:er är korrekt konfigurerade med ApplicationRegions eller PreferredRegions.

    Tip

    För bästa resultat bör globalt distribuerade program frontas av en global belastningsutjämningstjänst, till exempel Azure Front Door eller Azure Traffic Manager. Dessa tjänster kan identifiera regional försämring och automatiskt dirigera trafik till programinstanser i en felfri region.

  • Redistribution: De Azure Cosmos DB SDK:erna identifierar automatiskt att regionen är felaktig och omdirigerar läs- och skrivåtgärder till nästa tillgängliga region i listan över prioriterade regioner. Inga ändringar krävs i programkoden.

    Tip

    Om programmet frontas av Azure Front Door eller Traffic Manager identifierar dessa tjänster även regional försämring och dirigerar trafik till en felfri region.

Regionåterställning

När den berörda regionen är online igen visas regionen som "online" i Azure-portalen och blir tillgänglig igen.

Skrivdata som inte replikerades när regionen misslyckades görs 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.

Test för regionfel

Om du vill testa scenarier för skrivfel i flera regioner kan du koppla från en skrivregion med hjälp av en tvingad överväxling. Den här processen simulerar ett regionstopp och du kan se hur programmet svarar.

Säkerhetskopiering och återställning

För de flesta lösningar bör du inte enbart förlita dig på säkerhetskopior. Använd i stället de andra funktionerna som beskrivs i den här guiden för att stödja dina återhämtningskrav. Säkerhetskopior skyddar dock mot vissa risker som andra metoder inte gör. Mer information finns i Vad är redundans, replikering och säkerhetskopiering?.

Dataförlust kan inträffa på grund av oavsiktliga borttagningar eller andra problem i ditt program som orsakar skadade data. När du använder ett konto med en region kan förlust av data också inträffa på grund av en oåterställbar katastrof i Azure Cosmos DB-regionen. För att skydda dig mot dataförlust tillhandahåller Azure Cosmos DB en uppsättning säkerhetskopierings- och återställningsfunktioner. Du kan konfigurera säkerhetskopior och kvarhållning baserat på dina återställningskrav och kostnadskrav. Mer information finns i Onlinesäkerhetskopiering och återställning av data på begäran i Azure Cosmos DB.

Motståndskraft mot serviceunderhåll

Azure Cosmos DB hanterar transparent all information om enskilda beräkningsnoder och utför automatiskt korrigeringar och andra typer av planerat underhåll. De Azure Cosmos DB serviceavtalen för tillgänglighet och svarstid gäller för alla automatiska underhållsåtgärder som systemet utför.

Serviceavtal

Serviceavtal (SLA) för Azure-tjänster beskriver den förväntade tillgängligheten för varje tjänst och de villkor som din lösning måste uppfylla för att uppnå den tillgänglighetsförväntningen. Mer information finns i Serviceavtal för onlinetjänster.

Azure Cosmos DB tillhandahåller serviceavtal för en mängd olika konfigurationer och tjänstegenskaper, inklusive tillgänglighet, svarstid, dataflöde och konsekvens.

Serviceavtalen för tillgänglighet skiljer sig beroende på om du använder någon av följande produktfunktioner:

  • Tilldelad kapacitet
  • Enkelregionskonto med stöd för tillgänglighetszoner (zonredundans)
  • Konton som använder flera läsregioner
  • Konton som använder flera skrivregioner (affärskritisk nivå)

Relaterat innehåll

  • Last updated on