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.
Aby uzyskać więcej informacji na temat stref dostępności na platformie Azure, zobacz Co to są strefy dostępności?.
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 przez wszystkie operacje automatycznej konserwacji wykonywane przez system.
Oferuje usługę Azure Cosmos DB:
Odporność na awarie poszczególnych węzłów. Usługa Azure Cosmos DB automatycznie ogranicza awarie replik , gwarantując co najmniej trzy repliki danych w każdym regionie świadczenia usługi Azure dla konta w kworum z czterema replikami. Gwarantuje to, że cel czasu odzyskiwania 0 i cel punktu odzyskiwania 0 dla poszczególnych awarii węzłów bez konieczności wprowadzania zmian aplikacji lub konfiguracji.
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 udostępnia cel czasu odzyskiwania równy 0 i cel punktu odzyskiwania równy 0, nawet w przypadku awarii strefy. Aby uzyskać informacje na temat celu odzyskiwania, zobacz Cele odzyskiwania.
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 (powiązana 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 | Regiony zapisu i dowolna liczba regionów pomocniczych | Zapewnia większą dostępność operacji zapisu w przypadku niepowodzeń strefowych. |
| wszystkie | Pojedynczy region | Pojedynczy region nie może korzystać z możliwości trybu failover w wielu regionach. 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ą naliczane opłaty w wysokości 25% premium, natomiast te bez stref dostępności nie powodują naliczania premii. 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 bez stref dostępności | Zapisy w wielu regionach z jedną regionem ze strefami dostępności | Zapisy w wielu regionach z strefami dostępności lub bez tych operacji |
|---|---|---|---|---|---|
| Umowa SLA dotycząca dostępności zapisu | 99,99% | 99.995% | 99,99% | 99.995% | 99.999% |
| Umowa SLA dotycząca 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 |
| Błędy 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 dla błędu regionu odczytu, tymczasowy błąd regionu zapisu | Brak utraty dostępności dla błędu regionu odczytu, tymczasowy błąd regionu zapisu | Brak utraty dostępności odczytu, tymczasowa utrata dostępności zapisu w danym regionie |
| Cena (1) | Nie dotyczy | Aprowizowana liczba jednostek RU/s x 1,25 | Aprowizowane jednostki RU/s x N regionów | 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ć:
Migrowanie do obsługi strefy 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 dotyczy 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. Zanim zaczniesz myśleć o tworzeniu planu odzyskiwania po awarii, zobacz Zalecenia dotyczące projektowania strategii odzyskiwania po awarii.
Jeśli chodzi o odzyskiwanie po awarii, firma Microsoft korzysta z modelu wspólnej odpowiedzialności. W modelu wspólnej odpowiedzialności firma Microsoft zapewnia dostępność infrastruktury bazowej i usług platformy. Jednocześnie 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 regionu z włączoną obsługą. W przypadku tych usług odpowiadasz za skonfigurowanie planu odzyskiwania po awarii, który działa dla obciążenia. Większość usług uruchamianych na platformie Azure jako usługa (PaaS) oferuje funkcje i wskazówki dotyczące obsługi odzyskiwania po awarii. Funkcje specyficzne dla usługi umożliwiają szybkie odzyskiwanie w celu ułatwienia opracowania 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 są kopiami zapasowymi 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 w ramach konta 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 wszystkich poziomów spójności celu punktu odzyskiwania konta usługi Azure Cosmos DB wdrożonego w co najmniej dwóch regionach.
| Poziom spójności | Cel punktu odzyskiwania dla awarii regionu |
|---|---|
| Sesja, spójny prefiks, ostateczna | Mniej niż 15 minut |
| Powiązana 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 cel punktu odzyskiwania dla danych, gdy używasz powiązanej nieaktualnoś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.
Tryb failover zarządzany przez usługę
Jeśli twoje rozwiązanie wymaga ciągłego czasu pracy podczas przestojów w regionie, możesz skonfigurować usługę Azure Cosmos DB do replikowania danych w wielu regionach i przezroczystego przełączania w tryb failover do regionów operacyjnych, 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 przejścia w tryb failover są wykrywane i obsługiwane 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 przejście w tryb failover 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 zapisami w wielu regionach, jeden z regionów będzie działać jako arbiter w konfliktach zapisu.
Najlepsze rozwiązania dotyczące zapisów w wielu regionach
Poniżej przedstawiono kilka najlepszych rozwiązań, które należy wziąć pod uwagę podczas pisania w wielu regionach.
Zachowaj ruch lokalny
W przypadku korzystania z zapisów w wielu regionach aplikacja powinna wystawiać ruch odczytu i zapisu pochodzący z regionu lokalnego ściśle 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 zasad działania okrężnego w celu określenia regionu docelowego dla operacji odczytu lub zapisu dla poszczególnych żądań.
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, który jest zapisywany w celu odpowiadania natychmiast po replikacji danych w usłudze Azure Cosmos DB lokalnie, a asynchronicznie replikuje dane 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 blip w ruchu sieciowym lub wyższych niż zwykle współczynnikó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.
Ocena użycia 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ą utrwalania danych tylko wtedy, gdy serwer został przechwycony do podanego tokenu sesji. W przypadku kont zapisu w jednym regionie region zawsze gwarantuje się, że region zapisu jest uwikłany w token sesji. Jednak w przypadku kont zapisu w wielu regionach, region, do którego zapisujesz, może nie być w stanie przechwycić zapisów wystawionych 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.
Mimo że sporadyczne wzrosty liczby powtarzających się aktualizacji tego samego dokumentu są nieuniknione, warto rozważyć eksplorowanie architektury, w której tworzone są nowe dokumenty, jeśli ruch w stałym stanie widzi szybkie aktualizacje tego samego dokumentu w dłuższym okresie.
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 | Awaria | 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 usługi. Lub jeśli włączysz tryb failover zarządzany przez usługę, usługa oznaczy region jako niepowodzenie i nastąpi przejście w tryb failover. | Brak utraty danych. | Podczas awarii upewnij się, że w pozostałych regionach jest wystarczająca liczba aprowizowania jednostek żądań (RU), aby obsługiwać ruch 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 doświadczają utraty dostępności zapisu, dopóki usługa nie zarządza trybem failover w wybranym regionie 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 wystąpi duża liczba zapisów powodujących konflikt. | 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ła, możesz odpowiednio anulować 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 ostatnich zwycięstw zapisu. |
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, jest z powrotem w trybie online, synchronizuje się z bieżącym regionem zapisu i jest ponownie dostępny do obsługi żądań odczytu po jego pełnym przechwyceniu.
Dalsze operacje odczytu są przekierowywane do odzyskanego regionu bez konieczności wprowadzania jakichkolwiek zmian w kodzie aplikacji. Podczas przechodzenia w tryb failover i ponownego dołączania wcześniej nieudanego 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 określonego priorytetu regionu.
Ręczne przejście w tryb failover nie powinno być wyzwalane i nie powiedzie się w przypadku awarii regionu źródłowego lub docelowego. Przyczyną jest to, że procedura trybu failover obejmuje sprawdzanie spójności, które wymaga łączności między regionami.
Gdy region, którego dotyczy problem, jest z powrotem w trybie online, wszystkie dane zapisu, które nie zostały zreplikowane, gdy region zakończył się niepowodzeniem, zostanie udostępniony 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órym konto usługi Azure Cosmos DB promuje region pomocniczy jako nowy region zapisu podstawowego za pośrednictwem trybu failover zarządzanego przez usługę, oryginalny region zapisu nie zostanie podwyższony jako region zapisu automatycznie 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.
| Regiony zapisu | 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 regionu 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, 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. Gdy awaria się skończyła, możesz przenieść region zapisu z powrotem do oryginalnego regionu i odpowiednio usunąć 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 | Nie dotyczy | Ostatnio zaktualizowane dane w regionie, który zakończył się niepowodzeniem, mogą być niedostępne w pozostałych aktywnych regionach. Ostateczne, spójne prefiksy i poziomy spójności sesji gwarantują nieaktualność krótszą niż 15 minut. Powiązana 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ła, możesz odpowiednio anulować 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 odzyskiwanie korzysta z 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 odzyskiwanie używa ostatnich zwycięstw zapisu. |
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ść aplikacji w ramach testowania aplikacji lub testowania po awarii (DR), tymczasowo wyłącz tryb failover zarządzany 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 wrócić po awarii do regionu podstawowego i przywrócić zarządzany przez usługę tryb failover 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 przechodzenie w tryb failover wymaga łączności z regionem w celu zachowania spójności danych, więc nie powiedzie się.