Udostępnij za pośrednictwem

Wysoka dostępność (niezawodność) w usłudze Azure Cosmos DB for NoSQL

W tym artykule opisano obsługę wysokiej dostępności (niezawodności) w usłudze Azure Cosmos DB for NoSQL i opisano obie strefy dostępności, a także odzyskiwanie po awarii między regionami i ciągłość działania.

Obsługa strefy dostępności

Strefy dostępności są fizycznie oddzielnymi grupami centrów danych w każdym regionie świadczenia usługi Azure. Gdy jedna strefa ulegnie awarii, usługi mogą przejść w tryb failover do jednej z pozostałych stref.

Azure Cosmos DB to wielodostępna usługa, która w sposób przezroczysty zarządza wszystkimi szczegółami poszczególnych węzłów obliczeniowych. Nie musisz martwić się o jakiekolwiek stosowanie poprawek ani planowaną konserwację. Usługa Azure Cosmos DB gwarantuje umowy SLA dotyczące dostępności i opóźnienia P99 podczas wszystkich automatycznych prac konserwacyjnych wykonywanych przez system.

Azure Cosmos DB oferuje:

Odporność na awarie poszczególnych węzłów. Usługa Azure Cosmos DB automatycznie niweluje awarie replik, zapewniając co najmniej trzy repliki danych w każdym regionie Azure dla konta, w ramach kworum czterech replik. Gwarancja ta zapewnia RTO wynoszące 0 i RPO wynoszące 0 w przypadku awarii poszczególnych węzłów, bez konieczności wprowadzania zmian w aplikacjach lub konfiguracjach. Gdy włączysz nadmiarowość strefową, te repliki są rozproszone w wielu strefach dostępności, co zapewnia odporność na awarie i problemy w centrum danych.

Odporność na awarię strefy. Podczas wdrażania konta usługi Azure Cosmos DB przy użyciu stref dostępności, usługa Azure Cosmos DB zapewnia zerowy czas odzyskiwania (RTO) i zerowy punkt odzyskiwania (RPO), nawet w przypadku awarii strefy. Aby uzyskać informacje na temat RTO (celu czasowego odzyskiwania), zobacz Co to jest ciągłość działalności biznesowej, wysoka dostępność i odzyskiwanie po awarii?.

Po włączeniu stref dostępności usługa Azure Cosmos DB for NoSQL obsługuje konfigurację strefowo nadmiarową .

Wymagania wstępne

  • Repliki muszą być wdrażane w regionie świadczenia usługi Azure, który obsługuje strefy dostępności. Aby sprawdzić, czy region obsługuje strefy dostępności, zobacz listę obsługiwanych regionów.

  • Określ, czy strefy dostępności dodają wystarczającą wartość do bieżącej konfiguracji w sekcji Wpływ używania stref dostępności.

Wpływ korzystania ze stref dostępności

Wpływ stref dostępności na wysoką dostępność bazy danych Cosmos DB for NoSQL zależy od poziomu spójności konta i regionów z włączonymi strefami dostępności. W wielu przypadkach strefy dostępności nie dodają wartości ani nie dodają minimalnej wartości, jeśli konto jest w wielu regionach (chyba że skonfigurowano silną spójność).

Zapoznaj się z poniższą tabelą, aby oszacować wpływ używania stref dostępności w bieżącej konfiguracji konta:

Poziom spójności konta Regiony z włączonymi strefami dostępności Wpływ korzystania ze stref dostępności
Asynchroniczne (Ograniczona nieaktualność lub słabsza) Dowolna liczba pomocniczych regionów odczytu. Zapewnia minimalną wartość, ponieważ zestaw SDK zapewnia już bezproblemowe przekierowania dla operacji odczytu, gdy region odczytu zakończy się niepowodzeniem.
Synchroniczne (silne) Co najmniej dwa pomocnicze regiony odczytu Zapewnia wartość marginalną, ponieważ system może korzystać z dynamicznego kworum, jeśli region odczytu utraci dostępność, co umożliwia kontynuowanie zapisów.
Synchroniczne (silne) Jeden pomocniczy region odczytu Zapewnia większą wartość, ponieważ utrata regionu odczytu w tym scenariuszu może mieć wpływ na dostępność zapisu.
wszystkie Napisz regiony i dowolną liczbę regionów pomocniczych Zapewnia większą dostępność operacji zapisu w przypadku awarii strefowych.
wszystkie Pojedynczy region Pojedynczy region nie może korzystać z funkcji przełączania awaryjnego między wieloma regionami. Korzystanie ze stref dostępności chroni przed całkowitą utratą dostępności z powodu awarii strefowej.

Ulepszenia umowy SLA

Ponieważ strefy dostępności są fizycznie oddzielone i zapewniają odrębne źródło zasilania, sieć i chłodzenie, umowy SLA dotyczące dostępności (umowy dotyczące poziomu usług) są wyższe (99,995%) niż konta z jednym regionem (99,99%). Regiony, w których włączono strefy dostępności, są obciążone dodatkową opłatą w wysokości 25%, natomiast te bez stref dostępności nie powodują naliczania takiej opłaty. Ponadto ceny premium dla stref dostępności są wyłączane dla kont skonfigurowanych przy użyciu zapisów w wielu regionach i/lub kolekcji skonfigurowanych w trybie automatycznego skalowania.

Dodanie dodatkowego regionu do konta usługi Cosmos DB zwykle zwiększa istniejący rachunek o 100% (addytywne nie mnożenie), chociaż istnieją niewielkie różnice kosztów w różnych regionach. Aby uzyskać więcej informacji, zobacz stronę cennika.

Włączanie stref AZ, Dodanie dodatkowych regionów lub włączenie zapisów w wielu regionach może być uważane za podejście warstwowe, które zwiększa odporność i dostępność danego konta usługi Cosmos DB na każdym etapie — z dostępności jednego regionu bez konfiguracji AZ w jednym regionie przez 4 i pół 9 dla jednego regionu z włączoną opcją zapisu w wielu regionach. Zapoznaj się z poniższą tabelą, aby zapoznać się z podsumowaniem umów SLA dla każdej konfiguracji.

KLUCZOWY WSKAŹNIK WYDAJNOŚCI (KPI) Operacje zapisu w jednym regionie bez stref dostępności Zapisy w jednym regionie ze strefami dostępności Zapisy w wielu regionach i pojedynczych regionach bez stref dostępności Zapisy w wielu regionach i w jednym regionie ze strefami dostępności Zapisy w wielu regionach, z lub bez stref dostępności
SLA dotyczące dostępności zapisu danych 99,99% 99,995% 99,99% 99,995% 99.999%
SLA dotyczące dostępności odczytu 99,99% 99,995% 99.999% 99.999% 99.999%
Błędy strefy: utrata danych Utrata danych Brak utraty danych Brak utraty danych Brak utraty danych Brak utraty danych
Awarie strefy: dostępność Utrata dostępności Brak utraty dostępności Brak utraty dostępności Brak utraty dostępności Brak utraty dostępności
Awaria regionalna: utrata danych Utrata danych Utrata danych Zależne od poziomu spójności. Aby uzyskać więcej informacji, zobacz Spójność, dostępność i kompromisy dotyczące wydajności. Zależne od poziomu spójności. Aby uzyskać więcej informacji, zobacz Spójność, dostępność i kompromisy dotyczące wydajności. Zależne od poziomu spójności. Aby uzyskać więcej informacji, zobacz Spójność, dostępność i kompromisy dotyczące wydajności.
Awaria regionalna: dostępność Utrata dostępności Utrata dostępności Brak utraty dostępności w przypadku uszkodzenia regionu odczytu, tymczasowy w przypadku uszkodzenia regionu zapisu Brak utraty dostępności w przypadku uszkodzenia regionu odczytu, tymczasowy w przypadku uszkodzenia regionu zapisu Brak utraty dostępności odczytu, tymczasowa utrata dostępności zapisu w danym regionie
Cena (1) Nie dotyczy Zarezerwowane jednostki RU/s x współczynnik 1,25 Przydzielone jednostki RU/s x N regiony Aprowizowana liczba jednostek RU/s x 1,25 x regiony N (2) Szybkość zapisu w wielu regionach x N

1 W przypadku kont bezserwerowych jednostki RU są mnożone przez współczynnik 1,25.

2 Stawka 1,25 dotyczy tylko regionów, w których włączono strefy dostępności.

Tworzenie zasobu z włączonymi strefami dostępności

Strefy dostępności można skonfigurować tylko wtedy, gdy dodasz nowy region do konta NoSQL usługi Azure Cosmos DB.

Aby włączyć obsługę strefy dostępności, możesz użyć:

Przenieś się do obsługi stref dostępności

Aby dowiedzieć się, jak przeprowadzić migrację konta usługi Cosmos DB do obsługi stref dostępności, zobacz Migrowanie usługi Azure Cosmos DB for NoSQL do obsługi stref dostępności.

Odzyskiwanie po awarii między regionami i ciągłość działania

Odzyskiwanie po awarii (DR) odnosi się do praktyk używanych przez organizacje do odzyskiwania po wystąpieniu zdarzeń o dużym wpływie, takich jak klęski żywiołowe lub nieudane wdrożenia, które powodują przestoje i utratę danych. Niezależnie od przyczyny najlepszym rozwiązaniem dla awarii jest dobrze zdefiniowany i przetestowany plan odzyskiwania po awarii oraz projekt aplikacji, który aktywnie obsługuje odzyskiwanie po awarii. Przed rozpoczęciem tworzenia planu odzyskiwania po awarii zobacz Zalecenia dotyczące projektowania strategii odzyskiwania po awarii.

W przypadku DR firma Microsoft używa modelu wspólnej odpowiedzialności . W tym modelu firma Microsoft zapewnia dostępność podstawowej infrastruktury i usług platformy. Jednak wiele usług platformy Azure nie replikuje automatycznie danych ani nie wraca z regionu, w którym wystąpił błąd, aby przeprowadzić replikację krzyżową do innego włączonego regionu. W przypadku tych usług odpowiadasz za skonfigurowanie planu odzyskiwania po awarii, który odpowiada wymaganiom twojego obciążenia roboczego. Większość usług oferty platformy Azure jako usługa (PaaS) udostępnia funkcje i wskazówki wspierające DR. Możesz użyć funkcji specyficznych dla usługi, aby wspierać szybkie odzyskiwanie i ułatwić opracowanie planu odzyskiwania po awarii.

Awarie regionów to awarie wpływające na wszystkie węzły usługi Azure Cosmos DB w regionie świadczenia usługi Azure we wszystkich strefach dostępności. W rzadkich przypadkach awarii regionów można skonfigurować usługę Azure Cosmos DB tak, aby obsługiwała różne wyniki trwałości i dostępności.

Trwałość

Gdy konto usługi Azure Cosmos DB jest wdrażane w jednym regionie, zazwyczaj nie dochodzi do utraty danych. Dostęp do danych jest przywracany po odzyskaniu usług Azure Cosmos DB w danym regionie. Utrata danych może wystąpić tylko w przypadku nieodwracalnej awarii w regionie usługi Azure Cosmos DB.

Aby ułatwić ochronę przed całkowitą utratą danych, która może wynikać z katastroficznych awarii w regionie, usługa Azure Cosmos DB udostępnia dwa tryby tworzenia kopii zapasowych:

  • Ciągłe kopie zapasowe tworzą kopię zapasową każdego regionu co 100 sekund. Umożliwiają one przywrócenie danych do dowolnego punktu w czasie przy użyciu 1-sekundowego stopnia szczegółowości. W każdym regionie kopia zapasowa jest zależna od danych zatwierdzonych w tym regionie. Jeśli region ma włączone strefy dostępności, kopia zapasowa jest przechowywana na kontach magazynu strefowo nadmiarowego.
  • Okresowe kopie zapasowe w pełni tworzą kopię zapasową wszystkich partycji ze wszystkich kontenerów na koncie, bez synchronizacji między partycjami. Minimalny interwał tworzenia kopii zapasowej to 1 godzina.

Po wdrożeniu konta usługi Azure Cosmos DB w wielu regionach trwałość danych zależy od poziomu spójności skonfigurowanego na koncie. W poniższej tabeli przedstawiono szczegóły dotyczące RPO dla wszystkich poziomów spójności konta usługi Azure Cosmos DB, które jest wdrożone w co najmniej dwóch regionach.

Poziom spójności Odzyskiwanie punktu docelowego (RPO) dla awarii w regionie
Sesja, spójny prefiks, ostateczna Mniej niż 15 minut
Ustalona nieaktualność K i T
Silna 0

K = liczba wersji (czyli aktualizacji) elementu.

T = przedział czasu od ostatniej aktualizacji.

W przypadku kont z wieloma regionami minimalna wartość K i T wynosi 100 000 operacji zapisu lub 300 sekund. Ta wartość definiuje minimalny RPO dla danych, gdy używasz ograniczonej przestarzałości.

Aby uzyskać więcej informacji na temat różnic między poziomami spójności, zobacz Poziomy spójności w usłudze Azure Cosmos DB.

Zarządzanie przełączeniem awaryjnym przez usługę

Jeśli twoje rozwiązanie wymaga ciągłego czasu działania podczas przestojów w regionie, możesz skonfigurować usługę Azure Cosmos DB do replikowania danych w wielu regionach i automatycznego przełączania na regiony operacyjne, jeśli jest to wymagane.

Konta z jednym regionem mogą utracić dostępność po awarii regionalnej. Aby zapewnić ciągłość działalności biznesowej przez cały czas, zalecamy skonfigurowanie konta usługi Azure Cosmos DB przy użyciu jednego regionu zapisu i co najmniej drugiego regionu (odczytu) oraz włączenia trybu failover zarządzanego przez usługę.

Tryb failover zarządzany przez usługę umożliwia usłudze Azure Cosmos DB przełączanie w tryb failover w regionie zapisu konta z wieloma regionami w celu zachowania ciągłości działania kosztem utraty danych zgodnie z opisem we wcześniejszej sekcji Trwałość . Regionalne awarie są wykrywane i zarządzane w kliencie usługi Azure Cosmos DB. Nie wymagają żadnych zmian w aplikacji. Aby uzyskać instrukcje dotyczące włączania wielu regionów odczytu i trybu failover zarządzanego przez usługę, zobacz Zarządzanie kontem usługi Azure Cosmos DB przy użyciu witryny Azure Portal.

Ważne

Jeśli wybrano konfigurację zapisu w jednym regionie z wieloma regionami odczytu, zdecydowanie zalecamy skonfigurowanie kont usługi Azure Cosmos DB używanych na potrzeby obciążeń produkcyjnych w celu włączenia trybu failover zarządzanego przez usługę. Ta konfiguracja umożliwia usłudze Azure Cosmos DB przełączanie baz danych kont w tryb failover do dostępnych regionów. W przypadku braku tej konfiguracji konto utraci dostępność zapisu przez cały czas trwania awarii regionu zapisu. Ręczne przełączenie awaryjne nie powiedzie się z powodu braku łączności z regionem.

Ostrzeżenie

Nawet w przypadku włączenia trybu failover zarządzanego przez usługę częściowa awaria może wymagać ręcznej interwencji zespołu usługi Azure Cosmos DB. W tych scenariuszach przejście w tryb failover może potrwać do 1 godziny (lub więcej). Aby zapewnić lepszą dostępność zapisu podczas częściowych awarii, zalecamy włączenie stref dostępności oprócz trybu failover zarządzanego przez usługę.

Wiele regionów zapisu

Usługę Azure Cosmos DB można skonfigurować tak, aby akceptowała zapisy w wielu regionach. Ta konfiguracja jest przydatna do zmniejszenia opóźnienia zapisu w aplikacjach rozproszonych geograficznie.

Podczas konfigurowania konta usługi Azure Cosmos DB dla wielu regionów zapisu silna spójność nie jest obsługiwana, a mogą wystąpić konflikty zapisu. Aby uzyskać więcej informacji na temat rozwiązywania tych konfliktów, zobacz Typy konfliktów i zasady rozwiązywania problemów podczas korzystania z wielu regionów zapisu.

Ważne

Często aktualizowanie tego samego identyfikatora dokumentu (lub ponowne tworzenie tego samego identyfikatora dokumentu po TTL lub usunięciu) będzie miało wpływ na wydajność replikacji ze względu na większą liczbę konfliktów generowanych w systemie.  

Region rozwiązywania konfliktów

Gdy konto usługi Azure Cosmos DB jest skonfigurowane z możliwością zapisu w wielu regionach, jeden z regionów będzie pełnić rolę arbitra w przypadku konfliktów zapisu.

Najlepsze praktyki dotyczące operacji zapisu w wielu regionach

Poniżej przedstawiono kilka najlepszych rozwiązań, które należy wziąć pod uwagę podczas pisania w wielu regionach.

Utrzymuj lokalny ruch lokalnie

W przypadku korzystania z zapisów w wielu regionach aplikacja powinna przekierowywać ruch odczytu i zapisu z regionu lokalnego jedynie do lokalnego regionu usługi Cosmos DB. Aby uzyskać optymalną wydajność, unikaj wywołań między regionami.

Aplikacja musi zminimalizować konflikty, unikając następujących antywzorców:

  • Wysyłanie tej samej operacji zapisu do wszystkich regionów w celu zwiększenia szans na uzyskanie szybkiego czasu odpowiedzi

  • Losowe określanie regionu docelowego dla operacji odczytu lub zapisu dla poszczególnych żądań

  • Użycie polityki round-robin w celu określenia regionu docelowego dla operacji odczytu lub zapisu dla każdego żądania.

Unikanie zależności od opóźnienia replikacji

Nie można skonfigurować kont zapisu w wielu regionach w celu zapewnienia silnej spójności. Region, do którego zapisywane są dane, odpowiada natychmiast po lokalnej replikacji danych w usłudze Azure Cosmos DB, podczas gdy dane są asynchronicznie replikowane globalnie.

Chociaż jest rzadko, opóźnienie replikacji może wystąpić na jednej lub kilku partycjach podczas replikacji geograficznej danych. Opóźnienie replikacji może wystąpić z powodu rzadkiego skoku w ruchu sieciowym lub wyższych niż zwykle poziomów rozwiązywania konfliktów.

Na przykład architektura, w której aplikacja zapisuje dane w regionie A, ale odczyt z regionu B wprowadza zależność od opóźnienia replikacji między dwoma regionami. Jeśli jednak aplikacja odczytuje i zapisuje w tym samym regionie, wydajność pozostaje stała nawet w przypadku opóźnienia replikacji.

Oceń użycie spójności sesji dla operacji zapisu

W przypadku spójności sesji używasz tokenu sesji dla operacji odczytu i zapisu.

W przypadku operacji odczytu usługa Azure Cosmos DB wysyła buforowany token sesji do serwera z gwarancją odbierania danych odpowiadających określonemu (lub nowszemu) tokenowi sesji.

W przypadku operacji zapisu usługa Azure Cosmos DB wysyła token sesji do bazy danych z gwarancją zapisania danych tylko wtedy, gdy serwer nadgonił do podanego tokenu sesji. W przypadku kont z zapisem w jednym regionie gwarantuje się, że region zapisu zawsze jest zgodny z tokenem sesji. Jednak w przypadku kont z możliwością zapisu w wielu regionach, region, do którego zapisujesz, może nie nadążać za zapisami dokonanymi w innym regionie. Jeśli klient zapisuje dane w regionie A przy użyciu tokenu sesji z regionu B, region A nie będzie mógł utrwalyć danych, dopóki nie dogoni zmiany wprowadzone w regionie B.

Najlepiej używać tokenów sesji tylko w przypadku operacji odczytu, a nie operacji zapisu podczas przekazywania tokenów sesji między wystąpieniami klienta.

Eliminowanie szybkich aktualizacji tego samego dokumentu

Aktualizacje serwera w celu rozwiązania lub potwierdzenia braku konfliktów mogą kolidować z zapisami wyzwalanymi przez aplikację, gdy ten sam dokument jest wielokrotnie aktualizowany. Powtarzające się aktualizacje w krótkim odstępie czasu do tego samego dokumentu mają większe opóźnienia podczas rozwiązywania konfliktów.

Chociaż sporadyczne nasilenia powtarzających się aktualizacji tego samego dokumentu są nieuniknione, warto rozważyć zastosowanie architektury, w której tworzone są nowe dokumenty, jeśli w stanie ustalonym dochodzi do szybkich aktualizacji tego samego dokumentu przez dłuższy czas.

Awarie odczytu i zapisu

Klienci kont z jednym regionem utracą dostępność odczytu i zapisu do czasu przywrócenia usługi.

Konta z wieloma regionami mają różne zachowania w zależności od następujących konfiguracji i typów awarii.

Konfigurowanie Przerwa w dostawie Wpływ na dostępność Wpływ trwałości Postępowanie
Region pojedynczego zapisu Awaria regionu odczytu Wszyscy klienci automatycznie przekierowują odczyty do innych regionów. Nie ma utraty dostępności odczytu ani zapisu dla wszystkich konfiguracji. Wyjątkiem jest konfiguracja dwóch regionów z silną spójnością, która traci dostępność zapisu do czasu przywrócenia działania usługi. Lub jeśli włączysz zarządzany przez usługę tryb failover, usługa oznaczy region jako uszkodzony i nastąpi przejście w tryb failover. Brak utraty danych. Podczas awarii upewnij się, że w pozostałych regionach jest wystarczająca liczba aprowizowanych jednostek żądaniowych (RU) do obsługi ruchu odczytu.

Gdy awaria się skończyła, odpowiednio przesuń aprowizowane jednostki RU.
Region pojedynczego zapisu Awaria regionu zapisu Klienci przekierowują odczyty do innych regionów.

Bez trybu failover zarządzanego przez usługę klienci doświadczają utraty dostępności zapisu. Przywracanie dostępności zapisu odbywa się automatycznie po zakończeniu awarii.

W przypadku trybu failover zarządzanego przez usługę klienci odczuwają brak dostępności do zapisu, dopóki usługa nie przeprowadzi przełączenia awaryjnego do nowo wybranego regionu zapisu.		 Jeśli nie wybierzesz silnego poziomu spójności, usługa może nie replikować niektórych danych do pozostałych aktywnych regionów. Ta replikacja zależy od wybranego poziomu spójności. Jeśli region, którego dotyczy problem, ulegnie trwałej utracie danych, możesz utracić niereplikowane dane. Podczas awarii upewnij się, że w pozostałych regionach jest wystarczająca liczba aprowizowanych jednostek RU, aby obsługiwać ruch odczytu.

Nie wyzwalaj ręcznego przejścia w tryb failover podczas awarii, ponieważ nie może zakończyć się powodzeniem.

Gdy awaria się skończyła, odpowiednio przesuń aprowizowane jednostki RU. Konta korzystające z interfejsu API dla noSQL mogą również odzyskać niereplikowane dane w regionie, w którym wystąpiły awarie, ze źródła danych powodujących konflikt.
Wiele regionów zapisu Awaria regionalna Istnieje możliwość tymczasowej utraty dostępności zapisu, która jest analogiczna do pojedynczego regionu zapisu z trybem failover zarządzanym przez usługę. Przejście w tryb failover w regionie rozwiązywania konfliktów może również spowodować utratę dostępności zapisu, jeśli w momencie awarii pojawi się duża liczba zapisów konfliktowych. Ostatnio zaktualizowane dane w regionie, który zakończył się niepowodzeniem, mogą być niedostępne w pozostałych aktywnych regionach, w zależności od wybranego poziomu spójności. Jeśli region, którego dotyczy problem, ulegnie trwałej utracie danych, możesz utracić niereplikowane dane. Podczas awarii upewnij się, że w pozostałych regionach jest wystarczająca liczba zaaprowizowanych jednostek RU, aby obsługiwać większy ruch.

Gdy awaria się skończy, możesz odpowiednio dostosować aprowizowane jednostki RU. Jeśli to możliwe, usługa Azure Cosmos DB automatycznie odzyskuje niereplikowane dane w regionie, w którym wystąpił błąd. To automatyczne odzyskiwanie używa metody rozwiązywania konfliktów skonfigurowanej dla kont korzystających z interfejsu API dla NoSQL. W przypadku kont korzystających z innych interfejsów API to automatyczne odzyskiwanie używa zasady last write wins.

Dodatkowe informacje na temat awarii regionów odczytu

  • Region, którego dotyczy problem, jest odłączony i oznaczony w trybie offline. Zestawy SDK usługi Azure Cosmos DB przekierowują wywołania odczytu do następnego dostępnego regionu na liście preferowanych regionów.

  • Jeśli żadna z regionów na liście preferowanych regionów nie jest dostępna, wywołania automatycznie wracają do bieżącego regionu zapisu.

  • W kodzie aplikacji nie są wymagane żadne zmiany w celu obsługi awarii regionów odczytu. Gdy region odczytu, którego dotyczy problem, ponownie działa w trybie online, synchronizuje się z bieżącym regionem zapisu i jest znowu dostępny do obsługi żądań odczytu po całkowitym zsynchronizowaniu.

  • Dalsze operacje odczytu są przekierowywane do odzyskanego regionu bez konieczności wprowadzania jakichkolwiek zmian w kodzie aplikacji. Podczas przełączania awaryjnego i ponownego dołączania wcześniej awaryjnego regionu usługa Azure Cosmos DB nadal przestrzega gwarancji spójności odczytu.

  • Nawet w rzadkim i niefortunnym przypadku, w którym region zapisu platformy Azure jest trwale nieodwracalny, nie ma utraty danych, jeśli konto usługi Azure Cosmos DB w wielu regionach jest skonfigurowane z silną spójnością. Konto usługi Azure Cosmos DB z wieloma regionami ma charakterystykę trwałości określoną wcześniej w sekcji Trwałość .

Dodatkowe informacje na temat awarii regionów zapisu

  • Podczas awarii regionu zapisu konto usługi Azure Cosmos DB promuje region pomocniczy jako nowy podstawowy region zapisu, gdy na koncie usługi Azure Cosmos DB skonfigurowano tryb failover zarządzany przez usługę. Przejście w tryb failover odbywa się do innego regionu w kolejności priorytetu regionu, który określasz.

  • Ręczne przełączenie nie powinno być wyzwalane i nie powiedzie się w przypadku wystąpienia awarii w regionie źródłowym lub docelowym. Przyczyną jest to, że procedura trybu failover obejmuje sprawdzanie spójności, które wymaga łączności między regionami.

  • Gdy wcześniej dotknięty region wraca do trybu online, wszystkie dane zapisu, które nie zostały zreplikowane, gdy region uległ awarii, zostają udostępnione za pośrednictwem kanału informacyjnego konfliktów. Aplikacje mogą odczytywać zestawienie konfliktów, rozwiązywać konflikty na podstawie logiki specyficznej dla aplikacji i zapisywać zaktualizowane dane z powrotem do kontenera usługi Azure Cosmos DB zgodnie z potrzebami.

  • Po odzyskaniu wcześniej objętego regionu zapisu będzie on wyświetlany jako "online" w witrynie Azure Portal i stanie się dostępny jako region odczytu. W tym momencie można bezpiecznie przełączyć się z powrotem do odzyskanego regionu jako regionu zapisu przy użyciu programu [PowerShell, interfejsu wiersza polecenia platformy Azure lub witryny Azure Portal](/azure/cosmos-db/how-to-manage-database-account#perform-manual-failover-on-an-azure-cosmos-db-account. Nie ma danych ani utraty dostępności przed, podczas lub po przełączeniu regionu zapisu. Aplikacja nadal jest wysoce dostępna.

Ostrzeżenie

W przypadku awarii regionu zapisu, w której konto usługi Azure Cosmos DB awansuje region pomocniczy do roli nowego podstawowego regionu zapisu poprzez automatyczne przełączenie awaryjne zarządzane przez usługę, oryginalny region zapisu nie zostanie automatycznie przywrócony jako region zapisu po odzyskaniu. Twoim zadaniem jest przełączenie się z powrotem do odzyskanego regionu jako regionu zapisu przy użyciu programu PowerShell, interfejsu wiersza polecenia platformy Azure lub witryny Azure Portal (po uzyskaniu bezpieczeństwa, zgodnie z powyższym opisem).

Wykrywanie, powiadamianie i zarządzanie awariami

W przypadku kont z jednym regionem klienci tracą dostępność odczytu i zapisu podczas awarii regionu usługi Azure Cosmos DB. Konta z wieloma regionami mają różne zachowania, zgodnie z opisem w poniższej tabeli.

Pisz regiony Tryb failover zarządzany przez usługę Czego oczekiwać Postępowanie
Region pojedynczego zapisu Nie włączono Jeśli w regionie odczytu wystąpi awaria, gdy nie używasz silnej spójności, wszyscy klienci będą przekierowywać do innych regionów. Brak utraty dostępności odczytu lub zapisu i nie ma utraty danych. W przypadku korzystania z silnej spójności awaria w regionie odczytu może mieć wpływ na dostępność zapisu, jeśli pozostanie mniej niż dwa regiony odczytu.

Jeśli w regionie zapisu wystąpi awaria, klienci doświadczają utraty dostępności zapisu. Jeśli nie wybrano silnej spójności, usługa może nie replikować niektórych danych do pozostałych aktywnych regionów. Ta replikacja zależy od wybranego poziomu spójności. Jeśli region, którego dotyczy problem, ulegnie trwałej utracie danych, możesz utracić niereplikowane dane.

Usługa Azure Cosmos DB przywraca dostępność zapisu po zakończeniu awarii.		 Podczas awarii upewnij się, że w pozostałych regionach jest wystarczająca liczba aprowizowanych jednostek RU, aby obsługiwać ruch odczytu.

Nie wyzwalaj ręcznego przejścia w tryb failover podczas awarii, ponieważ nie może zakończyć się powodzeniem.

Gdy awaria się skończyła, odpowiednio przesuń aprowizowane jednostki RU.
Region pojedynczego zapisu Włączona Jeśli w regionie odczytu wystąpi awaria, gdy nie używasz silnej spójności, wszyscy klienci będą przekierowywać do innych regionów. Brak utraty dostępności odczytu lub zapisu i nie ma utraty danych. Jeśli używasz silnej spójności, awaria jednego z regionów odczytu może wpływać na dostępność zapisu, jeśli pozostanie mniej niż dwa regiony odczytu.

Jeśli w regionie zapisu wystąpi awaria, klienci doświadczają utraty dostępności zapisu, dopóki usługa Azure Cosmos DB nie wybierze nowego regionu jako nowego regionu zapisu zgodnie z preferencjami. Jeśli nie wybrano silnej spójności, usługa może nie replikować niektórych danych do pozostałych aktywnych regionów. Ta replikacja zależy od wybranego poziomu spójności. Jeśli region, którego dotyczy problem, ulegnie trwałej utracie danych, możesz utracić niereplikowane dane.		 Podczas awarii upewnij się, że w pozostałych regionach jest wystarczająca liczba aprowizowanych jednostek RU, aby obsługiwać ruch odczytu.

Nie wyzwalaj ręcznego przejścia w tryb failover podczas awarii, ponieważ nie może zakończyć się powodzeniem.

Kiedy awaria się zakończy, możesz przenieść region zapisu z powrotem do oryginalnego regionu i odpowiednio dostosować jednostki RU. Konta korzystające z interfejsu API dla noSQL mogą również odzyskać niereplikowane dane w regionie, w którym wystąpiły awarie, ze źródła danych powodujących konflikt.
Wiele regionów zapisu Nie dotyczy Ostatnio zaktualizowane dane w regionie, który zakończył się niepowodzeniem, mogą być niedostępne w pozostałych aktywnych regionach. Końcowe, spójne prefiksy oraz poziomy spójności sesji gwarantują opóźnienie krótsze niż 15 minut. Ograniczona nieaktualność gwarantuje mniej niż K aktualizacji lub T sekund, w zależności od konfiguracji. Jeśli region, którego dotyczy problem, ulegnie trwałej utracie danych, możesz utracić niereplikowane dane. Podczas awarii upewnij się, że w pozostałych regionach jest wystarczająca liczba zaaprowizowanych jednostek RU, aby obsługiwać większy ruch.

Gdy awaria się skończy, możesz odpowiednio dostosować aprowizowane jednostki RU. Jeśli to możliwe, usługa Azure Cosmos DB odzyskuje niereplikowane dane w regionie, w którym wystąpił błąd. To przywracanie korzysta z metody rozwiązywania konfliktów skonfigurowanej dla kont korzystających z interfejsu API NoSQL. W przypadku kont korzystających z innych interfejsów API to odzyskiwanie używa zasady "ostatni zapis wygrywa".

Testowanie pod kątem wysokiej dostępności

Nawet jeśli twoje konto usługi Azure Cosmos DB jest wysoce dostępne, aplikacja może nie być poprawnie zaprojektowana tak, aby zachować wysoką dostępność. Aby przetestować kompleksową wysoką dostępność swojej aplikacji w ramach testowania aplikacji lub testów odzyskiwania po awarii (DR), tymczasowo wyłącz przełączanie awaryjne zarządzane przez usługę dla konta. Wywołaj ręczne przejście w tryb failover przy użyciu programu PowerShell, interfejsu wiersza polecenia platformy Azure lub witryny Azure Portal, a następnie monitoruj aplikację. Po zakończeniu testu możesz przełączyć z powrotem do regionu podstawowego i przywrócić zarządzany przez usługę mechanizm przełączania awaryjnego dla konta.

Ważne

Nie należy wywoływać ręcznego przejścia w tryb failover podczas awarii usługi Azure Cosmos DB w regionie źródłowym lub docelowym. Ręczne przełączenie awaryjne wymaga łączności z regionem w celu zachowania spójności danych, dlatego się nie powiedzie.

Powiązana zawartość