Hög tillgänglighet (tillförlitlighet) i Azure Cosmos DB för NoSQL
Den här artikeln beskriver stöd för hög tillgänglighet (tillförlitlighet) i Azure CosmosDB för NoSQL och omfattar både tillgänglighetszoner samt haveriberedskap mellan regioner och affärskontinuitet.
Allmänna återhämtningsrekommendationer för Azure Cosmos DB för NoSQL finns i Återhämtningsrekommendationer för Azure Cosmos DB för NoSQL.
Stöd för tillgänglighetszon
Azure-tillgänglighetszoner är minst tre fysiskt separata grupper av datacenter i varje Azure-region. Datacenter i varje zon är utrustade med oberoende infrastruktur för ström, kylning och nätverk. Om det uppstår ett fel i den lokala zonen är tillgänglighetszoner utformade så att regionala tjänster, kapacitet och hög tillgänglighet stöds av de återstående två zonerna om den ena zonen påverkas.
Fel kan vara allt från programvaru- och maskinvarufel till händelser som jordbävningar, översvämningar och bränder. Tolerans mot fel uppnås med redundans och logisk isolering av Azure-tjänster. Mer detaljerad information om tillgänglighetszoner i Azure finns i Regioner och tillgänglighetszoner.
Azure-tillgänglighetszoner-aktiverade tjänster är utformade för att ge rätt nivå av tillförlitlighet och flexibilitet. De kan konfigureras på två sätt. De kan vara antingen zonredundanta, med automatisk replikering mellan zoner eller zoninstanser, med instanser fästa på en specifik zon. Du kan också kombinera dessa metoder. Mer information om zon- och zonredundant arkitektur finns i Rekommendationer för användning av tillgänglighetszoner och regioner.
Azure Cosmos DB är en tjänst för flera klienter som hanterar all information om enskilda beräkningsnoder transparent. Du behöver inte bekymra dig 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.
Azure Cosmos DB-erbjudanden:
Avbrott i enskilda noder. 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.
Zonstoppsåterhämtning. 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. Information om RTO finns i Återställningsmål.
Med tillgänglighetszoner aktiverade stöder Azure Cosmos DB for NoSQL en zonredundant konfiguration.
Förutsättningar
Dina repliker måste distribueras i en Azure-region 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.
Avgör om tillgänglighetszoner lägger till tillräckligt med värde för den aktuella konfigurationen i Effekten av att använda tillgänglighetszoner.
Effekten av att använda tillgänglighetszoner
Effekten av tillgänglighetszoner på den höga tillgängligheten för din Cosmos DB för NoSQL-databas beror på kontots konsekvensnivå och vilka regioner som har tillgänglighetszoner aktiverade. I många fall lägger tillgänglighetszoner inte till värde eller lägger till minimalt värde om kontot är flera regioner (om det inte har konfigurerats med stark konsekvens).
Se tabellen nedan för att uppskatta effekten av att använda tillgänglighetszoner i din aktuella kontokonfiguration:
| Kontokonsekvensnivå | Regioner med tillgänglighetszoner aktiverade | Effekten av att använda tillgänglighetszoner |
|---|---|---|
| Asynkron (begränsad inaktuellhet eller svagare) | Valfritt antal sekundära läsregioner. | Ger minimalt värde eftersom SDK:t redan tillhandahåller sömlösa omdirigeringar för läsningar när en läsregion misslyckas. |
| Synkron (stark) | Två eller flera sekundära läsregioner | Ger marginellt värde eftersom systemet kan utnyttja dynamiskt kvorum om en läsregion förlorar tillgängligheten, vilket gör att skrivningar kan fortsätta. |
| Synkron (stark) | En sekundär läsregion | Ger större värde eftersom förlusten av en läsregion i det här scenariot kan påverka skrivtillgängligheten. |
| Alla | Skrivregioner och valfritt antal sekundära regioner | Säkerställer större tillgänglighet för skrivåtgärder för zonfel. |
| Alla | Enskild region | En enskild region kan inte dra nytta av redundansfunktionen i flera regioner. Användning av tillgänglighetszoner skyddar mot total tillgänglighetsförlust på grund av zonfel. |
Förbättringar av serviceavtal
Eftersom tillgänglighetszoner är fysiskt åtskilda och ger distinkta energikällor, nätverk och kylning är serviceavtalen för tillgänglighet (serviceavtal) högre (99,995 %) än konton med en enda region (99,99 %). Regioner där tillgänglighetszoner är aktiverade debiteras med 25 % premium, medan de som saknar tillgänglighetszoner inte medför premium. Dessutom undantas premiumpriser för tillgänglighetszoner för konton som har konfigurerats med skrivningar i flera regioner och/eller för samlingar som konfigurerats med autoskalningsläge.
Om du lägger till ytterligare en region i Cosmos DB-kontot ökar vanligtvis den befintliga fakturan med 100 % (additivt inte multiplikativt) även om det finns små variationer i kostnaderna mellan regioner. Mer information finns på sidan med priser.
Att aktivera AZs, lägga till ytterligare regioner eller aktivera skrivningar i flera regioner kan betraktas som en skiktningsmetod som ökar återhämtning och tillgänglighet för ett visst Cosmos DB-konto vid varje steg på vägen – från 49:ors tillgänglighet för no-AZ-konfiguration för en enskild region, till och med 4 och hälften 9:or för en enda region med AZs, hela vägen till 5 9:ors tillgänglighet för konfiguration i flera regioner med alternativet för skrivning i flera regioner aktiverat. Se följande tabell för en sammanfattning av serviceavtal för varje konfiguration.
| 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.
Skapa en resurs med tillgänglighetszoner aktiverade
Du kan bara konfigurera tillgänglighetszoner när du lägger till en ny region i ett Azure Cosmos DB NoSQL-konto.
Om du vill aktivera stöd för tillgänglighetszoner kan du använda:
Migrera till stöd för tillgänglighetszoner
Information om hur du migrerar ditt Cosmos DB-konto till stöd för tillgänglighetszoner finns i Migrera Azure Cosmos DB för NoSQL till stöd för tillgänglighetszoner).
Haveriberedskap och affärskontinuitet mellan regioner
Haveriberedskap handlar om att återställa från händelser med hög påverkan, till exempel naturkatastrofer eller misslyckade distributioner som resulterar i driftstopp och dataförlust. Oavsett orsak är den bästa lösningen för en katastrof en väldefinierad och testad DR-plan och en programdesign som aktivt stöder DR. Innan du börjar fundera på att skapa en haveriberedskapsplan kan du läsa Rekommendationer för att utforma en strategi för haveriberedskap.
När det gäller dr använder Microsoft modellen för delat ansvar. I en modell med delat ansvar ser Microsoft till att baslinjeinfrastrukturen och plattformstjänsterna är tillgängliga. Samtidigt replikerar många Azure-tjänster inte automatiskt data eller återgår från en misslyckad region för att korsreparera till en annan aktiverad region. För dessa tjänster ansvarar du för att konfigurera en haveriberedskapsplan som fungerar för din arbetsbelastning. De flesta tjänster som körs på PaaS-erbjudanden (Plattform som en tjänst) i Azure ger funktioner och vägledning för att stödja DR och du kan använda tjänstspecifika funktioner för att stödja snabb återställning för att utveckla din DR-plan.
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:
- Kontinuerliga säkerhetskopior säkerhetskopierar varje region var 100:e sekund. De gör att du kan återställa dina data till valfri tidpunkt med 1 sekunds kornighet. I varje region är säkerhetskopieringen beroende av de data som har checkats in i den regionen. Om regionen har aktiverat tillgänglighetszoner lagras säkerhetskopieringen i zonredundanta lagringskonton.
- Periodiska säkerhetskopieringar säkerhetskopierar helt alla partitioner från alla containrar under ditt konto, utan synkronisering mellan partitioner. Det minsta säkerhetskopieringsintervallet är 1 timme.
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.
Tjänsthanterad redundans
Om lösningen kräver kontinuerlig drifttid under regionavbrott kan du konfigurera Azure Cosmos DB för att replikera dina data över flera regioner och transparent redundansväxla till driftregioner när det behövs.
Konton med en region kan förlora tillgängligheten efter ett regionalt avbrott. För att säkerställa affärskontinuitet 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 redundansväxling kan Azure Cosmos DB redundansväxla skrivregionen för ett konto med flera regioner för att bevara affärskontinuitet 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.
Läs- och skrivfel
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. Nu ä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](.. /cosmos-db/how-to-manage-database-account.yml#perform-manual-failover-on-an-azure-cosmos-db-account. 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).
Identifiering, avisering och hantering av avbrott
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. |
Testning för hög tillgänglighet
Ä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.