Vysoká dostupnost (spolehlivost) ve službě Azure Cosmos DB for NoSQL
Tento článek popisuje podporu vysoké dostupnosti (spolehlivosti) ve službě Azure Cosmos DB for NoSQL a pokrývá obě zóny dostupnosti a také zotavení po havárii napříč oblastmi a provozní kontinuitu.
Podpora zón dostupnosti
Zóny dostupnosti jsou fyzicky oddělené skupiny datacenter v rámci každé oblasti Azure. Když jedna zóna selže, můžou služby převzít služby při selhání jedné ze zbývajících zón.
Další informace o zónách dostupnosti v Azure najdete v tématu Co jsou zóny dostupnosti?.
Azure Cosmos DB je víceklientová služba, která transparentně spravuje všechny podrobnosti jednotlivých výpočetních uzlů. Nemusíte se starat o žádný druh 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í.
Azure Cosmos DB nabízí:
Odolnost proti výpadku jednotlivých uzlů 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.
Odolnost proti výpadku zóny. 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. Informace o RTO naleznete v tématu Cíle obnovení.
S povolenými zónami dostupnosti podporuje Azure Cosmos DB for NoSQL zónově redundantní konfiguraci.
Požadavky
Repliky musí být nasazené v oblasti Azure, která podporuje zóny dostupnosti. Pokud chcete zjistit, jestli vaše oblast podporuje zóny dostupnosti, podívejte se na seznam podporovaných oblastí.
Určete, jestli zóny dostupnosti přidají k vaší aktuální konfiguraci dostatečnou hodnotu v dopadu používání zón dostupnosti.
Dopad používání zón dostupnosti
Dopad zón dostupnosti na vysokou dostupnost databáze Cosmos DB for NoSQL závisí na úrovni konzistence účtu a na tom, které oblasti mají povolené zóny dostupnosti. V mnoha případech zóny dostupnosti nepřidají hodnotu ani nepřidají minimální hodnotu, pokud je účet více oblastí (pokud není nakonfigurovaný se silnou konzistencí).
Pokud chcete odhadnout dopad používání zón dostupnosti v konfiguraci vašeho aktuálního účtu, projděte si následující tabulku:
| Úroveň konzistence účtu | Oblasti s povolenými zónami dostupnosti | Dopad používání zón dostupnosti |
|---|---|---|
| Asynchronní (ohraničená nestarost nebo slabší) | Libovolný počet sekundárních oblastí čtení | Poskytuje minimální hodnotu, protože sada SDK již poskytuje bezproblémové přesměrování pro čtení v případě selhání oblasti čtení. |
| Synchronní (silná) | Dvě nebo více sekundárních oblastí čtení | Poskytuje mezní hodnotu, protože systém může využívat dynamické kvorum, pokud oblast čtení ztratí dostupnost, což umožňuje pokračovat zápisy. |
| Synchronní (silná) | Jedna sekundární oblast čtení | Poskytuje větší hodnotu, protože ztráta oblasti čtení v tomto scénáři může mít vliv na dostupnost zápisu. |
| Všechny | Zápis oblastí a libovolného počtu sekundárních oblastí | Zajišťuje větší dostupnost operací zápisu pro selhání zón. |
| Všechny | Jedna oblast | Jedna oblast nemůže těžit z funkce převzetí služeb při selhání ve více oblastech. Použití zón dostupnosti chrání před celkovou ztrátou dostupnosti kvůli selhání zón. |
Vylepšení smlouvy SLA
Vzhledem k tomu, že zóny dostupnosti jsou fyzicky oddělené a poskytují odlišný zdroj napájení, síť a chlazení, jsou smlouvy SLA o dostupnosti (smlouvy o úrovni služeb) vyšší (99,995 %) než účty s jednou oblastí (99,99 %). Oblasti, kde jsou povolené zóny dostupnosti, se účtují na 25 % premium, zatímco za oblasti bez zón dostupnosti se neúčtují premium. Kromě toho se pro účty nakonfigurované zápisy do více oblastí nebo pro kolekce nakonfigurované v režimu automatického škálování vzdávají ceny premium zón dostupnosti.
Přidání další oblasti do účtu služby Cosmos DB obvykle zvyšuje stávající fakturu o 100 % (sčítá se nenásobitelně), i když existují malé odchylky v nákladech napříč oblastmi. Další podrobnosti najdete na stránce s cenami.
Povolení AZ, přidání dalších oblastí nebo zapnutí zápisů do více oblastí je možné považovat za přístup vrstvení, který zvyšuje odolnost a dostupnost daného účtu Cosmos DB v každém kroku – od dostupnosti 4 9 pro konfiguraci bez AZ jedné oblasti až po 4 a polovinu 9 pro jednu oblast s AZs až do 5 9 dostupnosti pro konfiguraci více oblastí s povolenou možností zápisu do více oblastí. Souhrn smluv SLA pro každou konfiguraci najdete v následující tabulce.
| 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.
Vytvoření prostředku s povolenými zónami dostupnosti
Zóny dostupnosti můžete nakonfigurovat jenom v případě, že do účtu NoSQL služby Azure Cosmos DB přidáte novou oblast.
Pokud chcete povolit podporu zóny dostupnosti, můžete použít:
Migrace na podporu zóny dostupnosti
Informace o migraci účtu služby Cosmos DB do podpory zón dostupnosti najdete v tématu Migrace služby Azure Cosmos DB for NoSQL do podpory zóny dostupnosti).
Zotavení po havárii napříč oblastmi a provozní kontinuita
Zotavení po havárii (DR) se týká zotavení z událostí s vysokým dopadem, jako jsou přírodní katastrofy nebo neúspěšná nasazení, která vedou k výpadkům a ztrátě dat. Bez ohledu na příčinu je nejlepším řešením havárie dobře definovaný a otestovaný plán zotavení po havárii a návrh aplikace, který aktivně podporuje zotavení po havárii. Než začnete přemýšlet o vytvoření plánu zotavení po havárii, přečtěte si doporučení pro návrh strategie zotavení po havárii.
Pokud jde o zotavení po havárii, Microsoft používá model sdílené odpovědnosti. V modelu sdílené odpovědnosti Microsoft zajišťuje, aby byly dostupné základní služby infrastruktury a platformy. Současně mnoho služeb Azure automaticky nereplikuje data nebo se vrátí z oblasti, která selhala, aby se křížově replikovala do jiné povolené oblasti. Za tyto služby zodpovídáte za nastavení plánu zotavení po havárii, který funguje pro vaši úlohu. Většina služeb, které běží na nabídkách PaaS (Platforma jako služba) Azure, poskytuje funkce a pokyny pro podporu zotavení po havárii a pomocí funkcí specifických pro služby můžete podporovat rychlé obnovení , které vám pomůže s vývojem plánu zotavení po havárii.
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. Pokud má tato oblast povolené zóny dostupnosti, záloha se uloží v zónově redundantních účtech úložiště.
- 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.
Převzetí služeb při selhání spravované službou
Pokud vaše řešení vyžaduje nepřetržitou dobu provozu během výpadků oblastí, můžete službu Azure Cosmos DB nakonfigurovat tak, aby replikuje vaše data napříč několika oblastmi a v případě potřeby transparentně převzala služby při selhání do provozních oblastí.
Účty v jedné oblasti můžou po výpadku oblasti ztratit přístupnost. Pokud chcete zajistit nepřetržitou kontinuitu podnikových procesů, 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 provozní kontinuitu 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
Pomocí zásad kruhového dotazování určíte cílovou oblast operace čtení nebo zápisu pro jednotlivé požadavky.
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.
Výpadky čtení a zápisu
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](/azure/cosmos-db/how-to-manage-database-account#perform-manual-failover-on-an-azure-cosmos-db-account. 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).
Detekce výpadků, oznámení a správa
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. |
Testování pro zajištění vysoké dostupnosti
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é.