Dosažení vysoké dostupnosti s využitím služby Azure Cosmos DB

Článek
11/16/2023

PLATÍ PRO: NoSQL MongoDB Cassandra Gremlin Tabulka

Pokud chcete vytvořit řešení s vysokou dostupností, musíte vyhodnotit charakteristiky spolehlivosti všech jejích součástí. Azure Cosmos DB poskytuje funkce a možnosti konfigurace, které vám pomůžou dosáhnout vysoké dostupnosti vašeho řešení.

Tento článek používá následující termíny:

Cíl doby obnovení (RTO): Doba mezi začátkem výpadku, který ovlivňuje službu Azure Cosmos DB, a obnovením na plnou dostupnost.
Cíl bodu obnovení (RPO): Doba mezi posledním zápisem, který byl správně obnoven, a časem začátku výpadku, který ovlivňuje službu Azure Cosmos DB.

Poznámka:

Očekávané a maximální počet bodů obnovení a RTO závisí na druhu výpadku, ke kterému dochází ve službě Azure Cosmos DB. Například výpadek jednoho uzlu má jiné očekávané rto a cíl bodu obnovení než výpadek celé oblasti.

Tento článek podrobně popisuje události, které můžou ovlivnit dostupnost služby Azure Cosmos DB, a odpovídající možnosti konfigurace služby Azure Cosmos DB.

Údržba repliky

Azure Cosmos DB je víceklientová služba, která transparentně spravuje všechny podrobnosti jednotlivých výpočetních uzlů. Uživatelé si nemusí dělat starosti s žádným druhem oprav nebo plánované údržby. Azure Cosmos DB zaručuje smlouvy SLA pro dostupnost a latenci P99 prostřednictvím všech operací automatické údržby, které systém provádí.

Výpadky repliky

Výpadky replik jsou výpadky jednotlivých uzlů v clusteru Azure Cosmos DB, který je nasazený v oblasti Azure.

Azure Cosmos DB automaticky snižuje výpadky replik tím, že zaručuje alespoň tři repliky dat v každé oblasti Azure pro váš účet v rámci kvora čtyř replik. Výsledkem této záruky je rto 0 a cíl bodu obnovení 0 pro výpadky jednotlivých uzlů bez nutnosti změn nebo konfigurací aplikace.

V mnoha oblastech Azure je možné distribuovat cluster Azure Cosmos DB napříč zónami dostupnosti. Zóny dostupnosti můžou zvýšit smlouvy SLA, protože jsou fyzicky oddělené a poskytují odlišný zdroj napájení, síť a chlazení. Když nasadíte účet služby Azure Cosmos DB pomocí zón dostupnosti, azure Cosmos DB poskytuje rto 0 a cíl bodu obnovení 0, a to i v výpadku zóny.

Když nasadíte v jedné oblasti Azure, bez dalšího vstupu uživatele, je služba Azure Cosmos DB odolná vůči výpadkům uzlů. Díky povolení redundance napříč zónami dostupnosti je Služba Azure Cosmos DB odolná vůči výpadkům zón za cenu vyšších poplatků.

Redundanci zón můžete nakonfigurovat jenom v případech, kdy přidáváte novou oblast do účtu služby Azure Cosmos DB. U existujících oblastí můžete povolit redundanci zón odebráním oblasti a následným přidáním zpět s povolenou redundancí zóny. U účtu s jednou oblastí tento přístup vyžaduje, abyste dočasně při selhání přidali oblast a pak odeberete a přidáte požadovanou oblast s povolenou redundancí zóny.

Ve výchozím nastavení účet služby Azure Cosmos DB nepoužívá více zón dostupnosti. Nasazení napříč několika zónami dostupnosti můžete povolit následujícími způsoby:

Pokud je váš účet Služby Azure Cosmos DB distribuovaný napříč oblastmi Azure N , bude existovat N x 4 kopií všech vašich dat. Další informace o tom, jak Azure Cosmos DB replikuje data v jednotlivých oblastech, najdete v tématu Globální distribuce se službou Azure Cosmos DB. Mít účet služby Azure Cosmos DB ve více než dvou oblastech zlepšuje dostupnost vaší aplikace a poskytuje nízkou latenci napříč přidruženými oblastmi.

Výpadky oblastí

Výpadky oblastí jsou výpadky , které ovlivňují všechny uzly Azure Cosmos DB v oblasti Azure napříč všemi zónami dostupnosti. Ve výjimečných případech výpadků oblastí můžete službu Azure Cosmos DB nakonfigurovat tak, aby podporovala různé výsledky odolnosti a dostupnosti.

Stálost

Když je účet služby Azure Cosmos DB nasazený v jedné oblasti, obvykle nedojde ke ztrátě dat. Přístup k datům se obnoví po obnovení služeb Azure Cosmos DB v ovlivněné oblasti. Ke ztrátě dat může dojít pouze v případě neobnovitelné havárie v oblasti Azure Cosmos DB.

Azure Cosmos DB poskytuje dva režimy zálohování, které by mohly způsobit katastrofické havárie v oblasti, a pomáhá tak chránit před úplnou ztrátou dat:

Průběžné zálohování zálohuje každou oblast každých 100 sekund. Umožňují obnovit data k libovolnému bodu v čase s 1sekundovou členitostí. V každé oblasti je zálohování závislé na datech potvrzených v dané oblasti.
Pravidelné zálohy plně zálohují všechny oddíly ze všech kontejnerů v rámci vašeho účtu bez synchronizace napříč oddíly. Minimální interval zálohování je 1 hodina.

Když je účet služby Azure Cosmos DB nasazený ve více oblastech, stálost dat závisí na úrovni konzistence, kterou pro účet nakonfigurujete. Následující tabulka podrobně popisuje všechny úrovně konzistence, cíl bodu obnovení účtu služby Azure Cosmos DB, který je nasazen alespoň ve dvou oblastech.

Úroveň konzistence	Cíl bodu obnovení pro výpadek oblasti
Relace, konzistentní předpona, případná	Méně než 15 minut
Omezená neaktuálnost	K a T
Silné	0

K = počet verzí (tj. aktualizací) položky.

T = časový interval od poslední aktualizace.

U účtů s více oblastmi je minimální hodnota K a T 100 000 operací zápisu nebo 300 sekund. Tato hodnota definuje minimální cíl bodu obnovení (RPO) pro data, když používáte ohraničenou neakutnost.

Další informace o rozdílech mezi úrovněmi konzistence najdete v tématu Úrovně konzistence ve službě Azure Cosmos DB.

Dostupnost

Pokud vaše řešení vyžaduje nepřetržitou dostupnost během výpadků oblastí, můžete ve službě Azure Cosmos DB nakonfigurovat replikaci dat napříč několika oblastmi a transparentní převzetí služeb při selhání do dostupných oblastí v případě potřeby.

Účty v jedné oblasti můžou po výpadku oblasti ztratit dostupnost. Pokud chcete zajistit vysokou dostupnost vždy, doporučujeme nastavit účet služby Azure Cosmos DB s jednou oblastí zápisu a alespoň druhou oblastí (čtení) a povolit převzetí služeb při selhání spravované službou.

Převzetí služeb při selhání spravované službou umožňuje službě Azure Cosmos DB převzít služby při selhání oblasti zápisu účtu s více oblastmi, aby zachovala dostupnost za cenu ztráty dat, jak je popsáno výše v části Stálost . Místní převzetí služeb při selhání se detekuje a zpracovává v klientovi služby Azure Cosmos DB. Nevyžadují žádné změny z aplikace. Pokyny k povolení více oblastí čtení a převzetí služeb při selhání spravované službou najdete v tématu Správa účtu služby Azure Cosmos DB pomocí webu Azure Portal.

Důležité

Pokud jste zvolili konfiguraci zápisu do jedné oblasti s více oblastmi čtení, důrazně doporučujeme nakonfigurovat účty služby Azure Cosmos DB používané pro produkční úlohy pro povolení převzetí služeb při selhání spravované službou. Tato konfigurace umožňuje službě Azure Cosmos DB převzít služby při selhání databází účtů do dostupných oblastí. V případě absence této konfigurace dojde u účtu ke ztrátě dostupnosti zápisu po celou dobu výpadku oblasti zápisu. Ruční převzetí služeb při selhání nebude úspěšné kvůli nedostatku připojení k oblasti.

Upozorňující

I když je povolené převzetí služeb při selhání spravované službou, může částečné výpadky vyžadovat ruční zásah týmu služby Azure Cosmos DB. V těchto scénářích může trvat až 1 hodinu (nebo déle), než se převzetí služeb při selhání projeví. Pro lepší dostupnost zápisu během částečných výpadků doporučujeme povolit zóny dostupnosti kromě převzetí služeb při selhání spravované službou.

Více oblastí zápisu

Službu Azure Cosmos DB můžete nakonfigurovat tak, aby přijímala zápisy v několika oblastech. Tato konfigurace je užitečná pro snížení latence zápisu v geograficky distribuovaných aplikacích.

Při konfiguraci účtu služby Azure Cosmos DB pro více oblastí zápisu se nepodporuje silná konzistence a můžou nastat konflikty zápisu. Další informace o řešení těchto konfliktů najdete v tématu Typy konfliktů a zásady řešení při použití více oblastí zápisu.

Důležité

Časté aktualizace stejného ID dokumentu (nebo opakované vytvoření stejného ID dokumentu často po hodnotě TTL nebo odstranění) bude mít vliv na výkon replikace kvůli zvýšenému počtu konfliktů generovaných v systému.

Oblast řešení konfliktů

Pokud je účet služby Azure Cosmos DB nakonfigurovaný s více oblastmi zápisů, jedna z oblastí bude fungovat jako arbiter v konfliktech zápisu.

Osvědčené postupy pro zápisy do více oblastí

Tady je několik osvědčených postupů, které byste měli zvážit při psaní do více oblastí.

Zachování místního provozu v místním prostředí

Pokud používáte zápisy do více oblastí, měla by aplikace vydávat provoz čtení a zápisu pocházející z místní oblasti výhradně do místní oblasti Cosmos DB. Pokud chcete dosáhnout optimálního výkonu, vyhněte se volání mezi oblastmi.

Je důležité, aby aplikace minimalizovala konflikty tím, že se vyhnula následujícím antipatternům:

Odeslání stejné operace zápisu do všech oblastí za účelem zvýšení pravděpodobnosti rychlé odezvy
Náhodné určení cílové oblasti pro operaci čtení nebo zápisu na základě požadavku
Použití zásad kruhového dotazování k určení cílové oblasti operace čtení nebo zápisu na základě požadavku

Vyhněte se závislostem na prodlevě replikace

Pro silnou konzistenci nemůžete nakonfigurovat účty pro zápis do více oblastí. Oblast, která se zapisuje tak, aby reagovala okamžitě po replikaci dat do místního prostředí azure Cosmos DB a asynchronně replikuje data globálně.

I když dochází k občasné prodlevě replikace, může dojít k prodlevě replikace v jednom nebo několika oddílech, když provádíte geografickou replikaci dat. K prodlevě replikace může dojít kvůli vzácnému výpadku síťového provozu nebo vyššímu než obvyklému poměru řešení konfliktů.

Například architektura, ve které aplikace zapisuje do oblasti A, ale čte z oblasti B, představuje závislost na prodlevě replikace mezi těmito dvěma oblastmi. Pokud ale aplikace čte a zapisuje do stejné oblasti, zůstává výkon konstantní i v případě prodlevy replikace.

Vyhodnocení využití konzistence relace pro operace zápisu

V konzistenci relace použijete token relace pro operace čtení i zápisu.

V případě operací čtení služba Azure Cosmos DB odešle token relace uložené v mezipaměti na server se zárukou příjmu dat, která odpovídají zadanému (nebo novějšímu) tokenu relace.

V případě operací zápisu služba Azure Cosmos DB odešle token relace do databáze se zárukou zachování dat pouze v případě, že server zachytil poskytnutý token relace. V účtech pro zápis do jedné oblasti je vždy zaručeno, že se do tokenu relace zachytí oblast zápisu. V účtech pro zápis do více oblastí se však oblast, do které píšete, možná nezachytila zápisy vydané v jiné oblasti. Pokud klient zapíše do oblasti A s tokenem relace z oblasti B, oblast A nebude moct uchovávat data, dokud nezachytí změny provedené v oblasti B.

Nejlepší je použít tokeny relace pouze pro operace čtení a ne pro operace zápisu, pokud předáváte tokeny relace mezi instancemi klienta.

Zmírnění rychlých aktualizací stejného dokumentu

Aktualizace serveru, které se mají vyřešit nebo potvrdit, že absence konfliktů může kolidovat s zápisy aktivovanými aplikací při opakované aktualizaci stejného dokumentu. Opakované aktualizace v rychlém sledu stejného dokumentu mají při řešení konfliktů vyšší latenci.

I když občasné nárůsty opakovaných aktualizací stejného dokumentu jsou nevyhnutelné, můžete zvážit prozkoumání architektury, ve které se místo toho vytvoří nové dokumenty, pokud se v průběhu delšího období zobrazují rychlé aktualizace stejného dokumentu.

Co očekávat během výpadku oblasti

Klienti účtů s jednou oblastí budou mít ztrátu dostupnosti čtení a zápisu, dokud se služba neobnoví.

Účty s více oblastmi mají různé chování v závislosti na následujících konfiguracích a typech výpadků.

Konfigurace	Výpadek	Dopad na dostupnost	Dopad na odolnost	Co dělat
Jedna oblast zápisu	Výpadek oblasti čtení	Všichni klienti automaticky přesměrují čtení do jiných oblastí. Pro všechny konfigurace neexistuje žádná ztráta dostupnosti čtení nebo zápisu. Výjimkou je konfigurace dvou oblastí se silnou konzistencí, která ztrácí dostupnost zápisu do doby, než se služba obnovila. Nebo pokud povolíte převzetí služeb při selhání spravované službou, služba označí oblast jako neúspěšnou a dojde k převzetí služeb při selhání.	Žádná ztráta dat.	Během výpadku se ujistěte, že ve zbývajících oblastech existuje dostatek zřízených jednotek žádostí (RU), které podporují čtení provozu. Pokud je výpadek překonaný, podle potřeby se zřizují rezervované ru.
Jedna oblast zápisu	Výpadek oblasti zápisu	Klienti přesměrují čtení do jiných oblastí. Bez převzetí služeb při selhání dochází u klientů ke ztrátě dostupnosti zápisu. Při ukončení výpadku dojde k automatickému obnovení dostupnosti zápisu. Při převzetí služeb při selhání dochází u klientů ke ztrátě dostupnosti zápisu, dokud služba nespravuje převzetí služeb při selhání do nové oblasti zápisu, kterou vyberete.	Pokud nevyberete úroveň silné konzistence, nemusí služba replikovat některá data do zbývajících aktivních oblastí. Tato replikace závisí na vybrané úrovni konzistence. Pokud ovlivněná oblast trpí trvalou ztrátou dat, můžete ztratit nereplicitovaná data.	Během výpadku se ujistěte, že ve zbývajících oblastech je dostatek zřízených RU pro podporu čtení provozu. Během výpadku neaktivujte ruční převzetí služeb při selhání, protože nemůže proběhnout úspěšně. Pokud je výpadek překonaný, podle potřeby se zřizují rezervované ru. Účty, které používají rozhraní API pro NoSQL, můžou také obnovit nereplicitovaná data v oblasti, která selhala, z vašeho konfliktních informačního kanálu.
Více oblastí zápisu	Jakýkoli výpadek v jednotlivých oblastech	Existuje možnost dočasné ztráty dostupnosti zápisu, která je podobná jedné oblasti zápisu s převzetím služeb při selhání spravované službou. Převzetí služeb při selhání oblasti řešení konfliktů může také způsobit ztrátu dostupnosti zápisu, pokud v době výpadku dojde k velkému počtu konfliktních zápisů.	Nedávno aktualizovaná data v oblasti, která selhala, můžou být ve zbývajících aktivních oblastech nedostupná v závislosti na vybrané úrovni konzistence. Pokud ovlivněná oblast trpí trvalou ztrátou dat, může dojít ke ztrátě nereplicitních dat.	Během výpadku se ujistěte, že je ve zbývajících oblastech dostatek zřízených RU pro podporu většího provozu. Pokud je výpadek překonaný, můžete podle potřeby číst zřízené ru. Pokud je to možné, Azure Cosmos DB automaticky obnoví nereplicitovaná data v oblasti, která selhala. Toto automatické obnovení používá metodu řešení konfliktů, kterou konfigurujete pro účty, které používají rozhraní API pro NoSQL. Pro účty, které používají jiná rozhraní API, tato automatická obnovení používá poslední výhru zápisu.

Další informace o výpadcích oblasti čtení

Ovlivněná oblast je odpojená a označená jako offline. Sady SDK služby Azure Cosmos DB přesměrovávají volání čtení do další dostupné oblasti v seznamu upřednostňovaných oblastí.
Pokud není k dispozici žádná z oblastí v seznamu upřednostňovaných oblastí, volání se automaticky vrátí do aktuální oblasti zápisu.
Pro zpracování výpadků oblasti čtení se v kódu aplikace nevyžadují žádné změny. Když je ovlivněná oblast čtení zpět online, synchronizuje se s aktuální oblastí zápisu a je opět k dispozici k poskytování žádostí o čtení, jakmile ji plně zachytí.
Následná čtení se přesměrují na zotavenou oblast bez toho, aby se musel nějak změnit kód aplikace. Během převzetí služeb při selhání i při opětovném připojení k dříve neúspěšné oblasti služba Azure Cosmos DB nadále dodržuje záruky konzistence čtení.
I ve výjimečných a nešťastných případech, kdy je oblast zápisu Azure trvale nenapravitelná, nedojde ke ztrátě dat, pokud je váš účet Azure Cosmos DB s více oblastmi nakonfigurovaný se silnou konzistencí. Účet Azure Cosmos DB s více oblastmi má vlastnosti odolnosti uvedené dříve v části Stálost .

Další informace o výpadcích oblastí zápisu

Během výpadku oblasti zápisu podporuje účet služby Azure Cosmos DB sekundární oblast jako novou primární oblast zápisu, když je pro účet služby Azure Cosmos DB nakonfigurované převzetí služeb při selhání spravované službou. Převzetí služeb při selhání nastane v jiné oblasti v pořadí podle priority oblasti, kterou zadáte.
Ruční převzetí služeb při selhání by se nemělo aktivovat a nebude úspěšné v případě výpadku zdrojové nebo cílové oblasti. Důvodem je, že procedura převzetí služeb při selhání zahrnuje kontrolu konzistence, která vyžaduje připojení mezi oblastmi.
Když je dříve ovlivněná oblast zpět online, všechna zapisovaná data, která se nereplikovala, když se oblast nezdařila, je dostupná prostřednictvím kanálu konfliktů. Aplikace můžou číst informační kanál konfliktů, vyřešit konflikty na základě logiky specifické pro aplikaci a podle potřeby zapsat aktualizovaná data zpět do kontejneru Azure Cosmos DB.
Po obnovení dříve ovlivněné oblasti zápisu se na webu Azure Portal zobrazí jako online a zpřístupní se jako oblast pro čtení. V tomto okamžiku je bezpečné přepnout zpět do obnovené oblasti jako oblast zápisu pomocí PowerShellu, Azure CLI nebo webu Azure Portal. Před přepnutím oblasti zápisu nebo po přepnutí oblasti zápisu nedojde k žádné ztrátě dat ani dostupnosti. Vaše aplikace bude i nadále vysoce dostupná.

Upozorňující

V případě výpadku oblasti zápisu, kde účet služby Azure Cosmos DB podporuje sekundární oblast jako novou primární oblast zápisu prostřednictvím převzetí služeb při selhání spravované službou, původní oblast zápisu se nebude po obnovení automaticky propagovat. Je vaší zodpovědností přepnout zpět do obnovené oblasti jako oblast zápisu pomocí PowerShellu, Azure CLI nebo webu Azure Portal (jakmile je to bezpečné, jak je popsáno výše).

Smlouvy SLA

Následující tabulka shrnuje možnosti vysoké dostupnosti různých konfigurací účtů.

Ukazatel KPI	Zápisy do jedné oblasti bez zón dostupnosti	Zápisy do jedné oblasti se zónami dostupnosti	Zápisy do více oblastí bez zón dostupnosti	Zápisy do více oblastí s jednou oblastí se zónami dostupnosti	Zápisy do více oblastí s zónami dostupnosti nebo bez nich
Smlouva SLA o dostupnosti zápisu	99,99 %	99.995%	99,99 %	99.995%	99,999 %
Smlouva SLA o dostupnosti čtení	99,99 %	99.995%	99,999 %	99,999 %	99,999 %
Selhání zóny: Ztráta dat	Ztráta dat	Žádná ztráta dat	Žádná ztráta dat	Žádná ztráta dat	Žádná ztráta dat
Selhání zóny: dostupnost	Ztráta dostupnosti	Žádná ztráta dostupnosti	Žádná ztráta dostupnosti	Žádná ztráta dostupnosti	Žádná ztráta dostupnosti
Regionální výpadek: Ztráta dat	Ztráta dat	Ztráta dat	Závisí na úrovni konzistence. Další informace najdete v tématu Kompromisy mezi konzistencí, dostupností a výkonem.	Závisí na úrovni konzistence. Další informace najdete v tématu Kompromisy mezi konzistencí, dostupností a výkonem.	Závisí na úrovni konzistence. Další informace najdete v tématu Kompromisy mezi konzistencí, dostupností a výkonem.
Regionální výpadek: dostupnost	Ztráta dostupnosti	Ztráta dostupnosti	Žádná ztráta dostupnosti pro selhání oblasti čtení, dočasná pro selhání oblasti zápisu	Žádná ztráta dostupnosti pro selhání oblasti čtení, dočasná pro selhání oblasti zápisu	Žádná ztráta dostupnosti čtení, dočasná ztráta dostupnosti zápisu v ovlivněné oblasti
Cena (1)	Nelze použít	Zřízené RU/s x 1,25 sazby	Zřízené oblasti RU/s x N	Zřízené RU/s x 1,25 sazby x N oblasti (2)	Rychlost zápisu do více oblastí x N oblastí

1 U bezserverových účtů se ru vynásobí faktorem 1,25.

2 Sazba 1,25 se vztahuje pouze na oblasti, ve kterých povolíte zóny dostupnosti.

Tipy pro vytváření vysoce dostupných aplikací

Zkontrolujte očekávané chování sad SDK služby Azure Cosmos DB během událostí a konfigurace, které na ni mají vliv.
Pokud chcete zajistit vysokou dostupnost zápisu a čtení, nakonfigurujte účet služby Azure Cosmos DB tak, aby pokrývá alespoň dvě oblasti (nebo tři, pokud používáte silnou konzistenci). Další informace najdete v tématu Kurz: Nastavení globální distribuce služby Azure Cosmos DB pomocí rozhraní API pro NoSQL.
Pro účty Azure Cosmos DB s více oblastmi, které jsou nakonfigurované s jednou oblastí zápisu, povolte převzetí služeb při selhání spravované službou pomocí Azure CLI nebo webu Azure Portal. Jakmile povolíte převzetí služeb při selhání spravované službou, azure Cosmos DB převezme služby při selhání vašeho účtu bez jakéhokoli vstupu uživatele.
I když je váš účet Azure Cosmos DB vysoce dostupný, nemusí být vaše aplikace správně navržená tak, aby zůstala vysoce dostupná. Pokud chcete otestovat komplexní vysokou dostupnost vaší aplikace jako součást postupu testování nebo zotavení po havárii (DR), dočasně zakažte převzetí služeb při selhání spravované službou pro účet. Ruční převzetí služeb při selhání můžete vyvolat pomocí PowerShellu, Azure CLI nebo webu Azure Portal a pak monitorovat aplikaci. Po dokončení testu můžete převzít služby po obnovení do primární oblasti a obnovit převzetí služeb při selhání spravované službou pro účet.

Důležité

Během výpadku služby Azure Cosmos DB ve zdrojové nebo cílové oblasti nevyvolávejte ruční převzetí služeb při selhání. Ruční převzetí služeb při selhání vyžaduje připojení k oblasti kvůli zachování konzistence dat, takže nebude úspěšné.
V globálně distribuovaném databázovém prostředí existuje přímý vztah mezi úrovní konzistence a stálostí dat v případě výpadku v celé oblasti. Při vývoji plánu provozní kontinuity musíte pochopit maximální přijatelnou dobu, než se aplikace plně obnoví po rušivé události (to znamená RTO). Musíte také pochopit maximální dobu nedávných aktualizací dat, kterou může aplikace tolerovat ztrátu, když se obnoví po rušivé události (to znamená RPO). Další informace o RTO a RPO najdete v tématu Úrovně konzistence ve službě Azure Cosmos DB.

Co očekávat při výpadku oblasti Azure Cosmos DB

U účtů v jedné oblasti dochází u klientů ke ztrátě dostupnosti čtení a zápisu během výpadku oblasti Azure Cosmos DB. Účty s více oblastmi mají různé chování, jak je popsáno v následující tabulce.

Oblasti pro zápis	Převzetí služeb při selhání spravované službou	Co očekávat	Co dělat
Jedna oblast zápisu	Neaktivováno	Pokud dojde k výpadku v oblasti čtení, když nepoužíváte silnou konzistenci, všichni klienti se přesměrují do jiných oblastí. Nedojde ke ztrátě dostupnosti čtení nebo zápisu a nedojde ke ztrátě dat. Pokud použijete silnou konzistenci, může výpadek v oblasti čtení ovlivnit dostupnost zápisu, pokud zůstane méně než dvě oblasti čtení. Pokud dojde k výpadku v oblasti zápisu, dojde u klientů ke ztrátě dostupnosti zápisu. Pokud jste nevybrali silnou konzistenci, nemusí služba replikovat některá data do zbývajících aktivních oblastí. Tato replikace závisí na vybrané úrovni konzistence. Pokud ovlivněná oblast trpí trvalou ztrátou dat, může dojít ke ztrátě nereplicitních dat. Azure Cosmos DB obnoví dostupnost zápisu při ukončení výpadku.	Během výpadku se ujistěte, že ve zbývajících oblastech je dostatek zřízených RU pro podporu čtení provozu. Během výpadku neaktivujte ruční převzetí služeb při selhání, protože nemůže proběhnout úspěšně. Pokud je výpadek překonaný, podle potřeby se zřizují rezervované ru.
Jedna oblast zápisu	Povoleno	Pokud dojde k výpadku v oblasti čtení, když nepoužíváte silnou konzistenci, všichni klienti se přesměrují do jiných oblastí. Nedojde ke ztrátě dostupnosti čtení nebo zápisu a nedojde ke ztrátě dat. Pokud používáte silnou konzistenci, může výpadek oblasti čtení ovlivnit dostupnost zápisu, pokud zůstane méně než dvě oblasti čtení. Pokud dojde k výpadku v oblasti zápisu, klienti zaznamenanou ztrátu dostupnosti zápisu, dokud Azure Cosmos DB nevyvolí novou oblast zápisu podle vašich preferencí. Pokud jste nevybrali silnou konzistenci, nemusí služba replikovat některá data do zbývajících aktivních oblastí. Tato replikace závisí na vybrané úrovni konzistence. Pokud ovlivněná oblast trpí trvalou ztrátou dat, může dojít ke ztrátě nereplicitních dat.	Během výpadku se ujistěte, že ve zbývajících oblastech je dostatek zřízených RU pro podporu čtení provozu. Během výpadku neaktivujte ruční převzetí služeb při selhání, protože nemůže proběhnout úspěšně. Když dojde k výpadku, můžete oblast zápisu přesunout zpět do původní oblasti a odpovídajícím způsobem znovu načíst zřízené ru. Účty, které používají rozhraní API pro NoSQL, můžou také obnovit nereplicitovaná data v oblasti, která selhala, z vašeho kanálu konfliktů.
Více oblastí zápisu	Nelze použít	Nedávno aktualizovaná data v oblasti, která selhala, můžou být ve zbývajících aktivních oblastech nedostupná. Konečná, konzistentní předpona a úrovně konzistence relací zaručují nestaralost kratší než 15 minut. V závislosti na konfiguraci zaručuje ohraničená nestarost méně než aktualizace K nebo T sekund. Pokud ovlivněná oblast trpí trvalou ztrátou dat, může dojít ke ztrátě nereplicitních dat.	Během výpadku se ujistěte, že je ve zbývajících oblastech dostatek zřízených RU pro podporu většího provozu. Pokud je výpadek překonaný, můžete podle potřeby číst zřízené ru. Pokud je to možné, Azure Cosmos DB obnoví nereplicitovaná data v oblasti, která selhala. Toto obnovení používá metodu řešení konfliktů, kterou konfigurujete pro účty, které používají rozhraní API pro NoSQL. Pro účty, které používají jiná rozhraní API, používá toto obnovení poslední výhru zápisu.

Další kroky

Dále si můžete přečíst následující články: