Osvědčené postupy replikace mezi regiony a v rámci stejného regionu v Azure DocumentDB

Tento článek popisuje zotavení po havárii napříč oblastmi (DR) pro Azure DocumentDB. Zahrnuje také možnosti čtení clusterů replik ve stejných nebo jiných oblastech Azure pro zajištění škálovatelnosti operací čtení.

Funkce replikace umožňuje replikovat data z clusteru do clusteru jen pro čtení v jiné nebo stejné oblasti Azure. Repliky se aktualizují pomocí technologie asynchronní replikace. Pro primární cluster Azure DocumentDB můžete mít jednu repliku clusteru v jiné oblasti. Ve výjimečných případech výpadku oblasti můžete zvýšit úroveň repliky clusteru v jiné oblasti, aby se stal novým clusterem pro čtení i zápis pro průběžný provoz databáze MongoDB. Aplikace můžou po povýšení repliky clusteru v jiné oblasti dál používat stejné připojovací řetězec, aby se stal novým primárním clusterem.

Repliky jsou nové clustery, které se spravují podobně jako běžné clustery. Za každou repliku pro čtení se vám účtuje zřízený výpočetní výkon ve virtuálních jádrech a úložiště v GiB za měsíc. Náklady na výpočetní prostředky a úložiště pro clustery replik mají stejnou strukturu jako běžné clustery a ceny oblasti Azure, ve které se vytvářejí.

Zotavení po havárii s využitím clusterů replik

Replikace mezi oblastmi je jedním z několika důležitých pilířů strategie provozní kontinuity a zotavení po havárii Azure (BCDR). Replikace mezi oblastmi asynchronně replikuje stejné aplikace a data napříč ostatními oblastmi Azure pro ochranu zotavení po havárii. Ne všechny služby Azure automaticky replikují data nebo automaticky přejdou z oblasti, která selhala, aby přenesly data do jiné povolené oblasti. Azure DocumentDB nabízí možnost vytvořit repliku clusteru v jiné oblasti a automaticky replikovat data zapisovaná do primárního clusteru do této repliky. Pokud dojde k výpadku v primární oblasti, musí být náhradní replika clusteru inicializována ručně.

Pokud je v clusteru Azure DocumentDB povolená replikace mezi oblastmi, každý horizontální oddíl se průběžně replikuje do jiné oblasti. Tato replikace udržuje repliku dat ve vybrané oblasti. Tato replika je připravená k použití jako součást plánu zotavení po havárii ve výjimečných případech výpadku primární oblasti. Replikace je asynchronní. Operace zápisu na shardu primárního clusteru nečekají na dokončení replikace na odpovídající shard repliky před odesláním potvrzení o úspěšném zápisu. Asynchronní replikace pomáhá vyhnout se zvýšeným latencím operací zápisu v primárním clusteru.

Průběžné zápisy, operace čtení na replikách clusteru a připojovací řetězec

Globální připojovací řetězec pro čtení a zápis v Azure DocumentDB konzistentně směruje zápisy do aktivního clusteru s podporou zápisu. Když zahájíte aktivaci replikového clusteru, replikový cluster v oblasti B se přepne do režimu zápisu, zatímco původní primární cluster v oblasti A přejde na režim pouze pro čtení. Před povýšením globální připojovací řetězec pro čtení a zápis cílí na primární cluster v oblasti A a poté se aktualizuje, aby ukazoval na oblast B, protože přebírá odpovědnost za zápis. U aplikací, které používají globální připojovací řetězec pro čtení i zápis, operace zápisu plynule pokračují v procesu povýšení a udržují nepřerušovaný tok dat.

Clustery replik jsou také k dispozici pro čtení. Pomáhá snižovat náročné operace čtení z primárního clusteru nebo poskytovat nižší latenci operací čtení klientům umístěným blíže k oblasti replikace. Pokud je povolena replikace mezi regiony, mohou aplikace použít připojovací řetězec repliky clusteru k provádění čtení z této repliky. Primární cluster je k dispozici pro operace čtení a zápisu pomocí vlastního připojovacího řetězce.

Snímek obrazovky s připojovacími řetězci clusteru v Azure DocumentDB, včetně globálního připojovacího řetězce pro čtení i zápisu a vlastního připojovacího řetězce

Když vytvoříte repliku povolením replikace mezi regiony nebo v rámci stejného regionu, nezdědí nastavení sítě, jako jsou pravidla firewallu primárního clusteru. Tato nastavení musí být pro repliku nastavená nezávisle. Replika dědí účet správce z primárního clusteru. Uživatelské účty je potřeba spravovat v primárním clusteru. Ke primárnímu clusteru a clusteru repliky se můžete připojit pomocí stejných uživatelských účtů.

Povýšení repliky clusteru

Pokud dojde k výpadku oblasti, můžete provést operaci zotavení po havárii zvýšením úrovně repliky clusteru v jiné oblasti, aby byla k dispozici pro zápisy. Během operace povýšení repliky dochází k těmto krokům:

  1. Zápisy na repliku v oblasti B jsou kromě čtení povolené. Bývalá replika se stane novým clusterem pro čtení i zápis.
  2. Povýšený cluster repliky v oblasti B přijímá zápisy prostřednictvím připojovacích řetězců a globálního připojovacího řetězce pro čtení i zápis.
  3. Cluster v oblasti A je nastavený na pouze pro čtení a udržuje připojovací řetězec.

Important

Vzhledem k tomu, že replikace je asynchronní, nemusí se některá data z clusteru v oblasti A replikovat do oblasti B, když se zvýší úroveň repliky clusteru v oblasti B. Pokud ano, povýšení by vedlo k tomu, že se v obou clusterech nenachází duplicitní data.

Metody ověřování v clusterech replik

Metody ověřování se spravují nezávisle na primárním clusteru a clusterech replik. Uživatelé a další objekty zabezpečení, jako jsou spravované identity, se vždy spravují v primárním clusteru a synchronizují se s clusterem repliky.

Pokud má primární cluster v době vytvoření clusteru repliky zakázanou nativní metodu ověřování DocumentDB, povolení nativního ověřování DocumentDB na replice není povolené. Pokud chcete na takové replice povolit nativní ověřování DocumentDB, musí se nejprve zvýšit jeho úroveň.

Související obsah

  • Last updated on