Niezawodność w Azure Cosmos DB

Azure Cosmos DB dla NoSQL jest globalnie rozproszoną usługą wielomodelowej bazy danych, która obsługuje modele danych dokumentów z elastycznymi schematami. Azure Cosmos DB oferuje kompleksowe funkcje niezawodności, w tym wiele poziomów spójności, które umożliwiają równoważenie wydajności i dostępności, wdrożenia ze strefową nadmiarowością, które chronią przed awariami stref dostępności, replikację w wielu regionach z trybem failover zarządzanym przez usługę lub klienta oraz ciągłe i okresowe tworzenie kopii zapasowych na potrzeby ochrony danych.

W przypadku korzystania z platformy Azure niezawodność jest wspólną odpowiedzialnością. Microsoft oferuje szereg funkcjonalności wspierających odporność i odzyskiwanie. Odpowiadasz za zrozumienie, jak te możliwości działają w ramach wszystkich używanych usług oraz za wybór tych, które są potrzebne do osiągnięcia Twoich celów biznesowych i celów dotyczących niezawodności.

W tym artykule opisano, jak zapewnić odporność Azure Cosmos DB na różne potencjalne awarie i problemy, w tym przejściowe błędy, awarie strefy dostępności, awarie regionów i konserwacja usługi. Opisano również, jak używać kopii zapasowych do odzyskiwania po innych typach problemów i wyróżnia kluczowe informacje o umowie dotyczącej poziomu usług (SLA) Azure Cosmos DB.

Zalecenia dotyczące wdrażania produkcyjnego

Platforma Azure Well-Architected Framework udostępnia zalecenia dotyczące niezawodności, zabezpieczeń, kosztów, operacji i wydajności. Aby zrozumieć, jak te obszary wpływają na siebie nawzajem i jak przyczyniają się do niezawodnego rozwiązania Azure Cosmos DB, zapoznaj się z najlepszymi praktykami dotyczącymi Azure Cosmos DB.

Omówienie architektury niezawodności

W tej sekcji opisano niektóre ważne aspekty działania usługi, które są najbardziej istotne z perspektywy niezawodności. W sekcji przedstawiono architekturę logiczną, która zawiera niektóre z zasobów i funkcji wdrażanych i używanych. Omówiono również architekturę fizyczną, która zawiera szczegółowe informacje na temat działania usługi za kulisami.

Architektura logiczna

Wdrażany zasób podstawowy to konto Azure Cosmos DB account. Każde konto może mieć wiele baz danych z wieloma kontenerami. Kontenery służą jako jednostki logiczne dystrybucji i skalowalności. Kontenery, takie jak kolekcje, tabele i grafy, można tworzyć w zależności od interfejsu API używanego do interakcji z Azure Cosmos DB. Aby uzyskać więcej informacji na temat modelu zasobów, zobacz Databases, containers i items in Azure Cosmos DB (Bazy danych, kontenery i elementy). Każdy kontener używa partycjonowania, które obsługuje dużą skalowalność i wysoką wydajność.

Konfigurujesz przepływność, która reprezentuje ilość zasobów systemowych, których można użyć do wykonywania zapytań i pracy z danymi. Możesz ręcznie aprowizować przepływność, użyć autoskalowania , aby dynamicznie dostosować pojemność na podstawie wymagań obciążenia lub użyć typu konta bezserwerowego do naliczania opłat za rzeczywiste użycie.

Pojedyncze konto może obejmować wiele regionów Azure, co zwiększa odporność na awarie regionów. Możesz skonfigurować wiele regionów do odczytu, a jeśli używasz warstwy Krytyczne dla działania firmy, możesz użyć wielu regionów do pisania. Azure Cosmos DB automatycznie replikuje dane geograficznie. Zachowanie replikacji geograficznej ma wpływ na używaną konfigurację, taką jak poziom spójności, który wskazuje, jak chcesz dokonać kompromisów między spójnością danych, dostępnością, opóźnieniami i przepływnością. Różne poziomy spójności optymalizują się pod kątem różnych zagadnień, obsługują różne gwarancje i zapewniają różne typy replikacji między regionami.

Architektura fizyczna

Azure Cosmos DB przechowuje wiele replik danych w celu zapewnienia nadmiarowości. Usługa automatycznie łagodzi skutki awarii replik, utrzymując kworum wśród replik w każdej lokalizacji. Takie podejście gwarantuje wysoką dostępność i chroni przed utratą danych podczas awarii poszczególnych węzłów bez konieczności wprowadzania zmian aplikacji ani konfiguracji.

Wewnętrznie Azure Cosmos DB zarządza danymi za pomocą różnych konstrukcji, w tym partycji fizycznych, zestawów partition sets i replica sets. Aby uzyskać bardziej szczegółowe informacje na temat działania Azure Cosmos DB, zobacz Globalna dystrybucja danych z Azure Cosmos DB - pod maską.

Odporność na błędy przejściowe

Błędy przejściowe to krótkotrwałe, sporadyczne awarie w komponentach. Występują one często w środowisku rozproszonym, takich jak chmura, i są one normalną częścią operacji. Błędy przejściowe naprawiają się po krótkim czasie. Ważne jest, aby aplikacje mogły obsługiwać błędy przejściowe, zwykle ponawiając próby żądań, których dotyczy problem.

Wszystkie aplikacje hostowane w chmurze powinny postępować zgodnie ze wskazówkami dotyczącymi obsługi błędów przejściowych platformy Azure podczas komunikowania się z dowolnymi interfejsami API hostowanymi w chmurze, bazami danych i innymi składnikami. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące obsługi błędów przejściowych.

Zalecamy używanie zestawów SDK Azure Cosmos DB. Zestawy SDK automatycznie implementują obsługę szeregu zagadnień dotyczących odporności, w tym obsługi błędów przejściowych za pomocą automatycznych ponownych prób i honorowania odpowiedzi limitu szybkości wysyłanych przez usługę. Aby uzyskać więcej informacji, zobacz Tworzenie odpornych aplikacji przy użyciu zestawów SDK Azure Cosmos DB.

Podczas pracy z kontem wieloregionowym zestaw SDK obsługuje również strategię dostępności opartą na progach, nazywaną również zabezpieczaniem, w której wysyła równoległe żądania odczytu do wielu regionów i akceptuje najszybszą odpowiedź. Takie podejście może poprawić wydajność aplikacji, gdy region tymczasowo doświadcza większego opóźnienia niż zwykle.

Odporność na błędy strefy dostępności

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

Usługa Azure Cosmos DB obsługuje nadmiarowość stref. Po włączeniu nadmiarowości strefowej platforma Azure dystrybuuje repliki Twoich danych w wielu strefach dostępności, co zapewnia odporność na problemy i awarie w centrach danych. Microsoft wybiera strefy dostępności do użycia.

Diagram przedstawiający konto Azure Cosmos DB z zestawem replik zawierającym trzy repliki rozproszone w trzech oddzielnych strefach dostępności.

Konto Azure Cosmos DB może używać wielu regionów (lokalizacji) do dystrybucji globalnej, skalowania i trybu failover. Nadmiarowość strefy jest konfigurowana oddzielnie dla każdego regionu na koncie.

Użycie nadmiarowości strefy w Azure Cosmos DB nie ma zauważalnego wpływu na wydajność lub opóźnienie. Nie wymaga żadnych zmian w wybranym trybie spójności i nie wymaga żadnych modyfikacji kodu aplikacji.

Zalecamy używanie redundancji stref w regionach, w których jest wspierana, zwłaszcza dla kont jednoregionowych. 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 dla usługi Azure Cosmos DB są wyższe dla kont strefowo nadmiarowych niż konta, które nie korzystają ze stref dostępności.

Wskazówka

Włączenie redundancji strefowej to doskonały sposób, aby zwiększyć odporność bazy danych Azure Cosmos DB bez wprowadzania dodatkowych złożoności aplikacji lub negatywnego wpływu na wydajność. W zależności od konfiguracji konta może nawet nie ponosić dodatkowych kosztów.

Jeśli nie włączysz redundancji stref, konto jest nieprzypisane do strefy w tym regionie. Niezonalne konta mogą umieszczać repliki w pojedynczej strefie dostępności, co może prowadzić do przestoju, jeśli ta konkretna strefa napotka problem.

Requirements

  • Region support: Możesz włączyć nadmiarowość strefową w regionach Azure, które obsługują strefy dostępności. Aby sprawdzić, czy region obsługuje strefy dostępności, zobacz listę obsługiwanych regionów.

    Nadmiarowość strefy nie jest ustawieniem obejmującym całe konto. Azure Cosmos DB konta mogą obejmować wiele regionów, a każdy region można skonfigurować niezależnie pod kątem używania stref dostępności. Regiony, które nie obsługują stref dostępności, nie uniemożliwiają włączenia nadmiarowości w strefach w innych regionach w ramach tego samego konta.

  • Konta bezserwerowe: Można skonfigurować konta bezserwerowe z nadmiarowością strefową tylko podczas ich tworzenia. Nie można przekonwertować istniejących kont bezserwerowych bez stref dostępności na konfigurację strefy dostępności. W przypadku obciążeń o znaczeniu krytycznym zalecamy użycie aprowizowanej przepływności.

Zagadnienia do rozważenia

  • Wiele równoczesnych przerw w działaniu stref: Konto jednostrefowe z nadmiarowością stref może zachować dostępność odczytu i zapisu, gdy awaria dotknie pojedynczą strefę dostępności. Jeśli jednak awaria wpłynie na wiele stref dostępności lub całego regionu, konta z jednym regionem utracą dostęp do odczytu i zapisu do momentu przywrócenia usługi. Rozważ wdrożenie konta z wieloma regionami, jeśli musisz być odporny na awarie wielu stref w tym samym czasie.

  • Konta z wieloma regionami: Jeśli masz konto z wieloma regionami, możesz włączyć opcjonalnie redundancję strefy w dowolnym bądź we wszystkich regionach konta, które obsługują strefy dostępności. Zdecydowanie zalecamy włączenie strefowej nadmiarowości, gdy konto jest skonfigurowane do korzystania z pojedynczego regionu lub jeśli jest skonfigurowane do korzystania z pojedynczego regionu zapisu z wieloma regionami odczytu.

Koszt

Regiony, w których włączono nadmiarowość stref, są obciążone dodatkowymi kosztami. Jednak opłaty premium dla stref dostępności są znoszone dla kont skonfigurowanych z zapisami do wielu regionów oraz dla kolekcji skonfigurowanych do korzystania z trybu automatycznego skalowania przepustowości. Aby uzyskać więcej informacji, zobacz Cennik usługi Azure Cosmos DB.

Konfiguruj obsługę stref dostępności

W przypadku większości kont można włączyć nadmiarowość strefy tylko wtedy, gdy do konta Azure Cosmos DB zostanie dodany nowy region. Aby włączyć obsługę strefy dostępności na istniejącym koncie, dodaj region i włącz na nim nadmiarowość strefy. Możesz wykonać proces dodawania regionu tymczasowego, aby skonfigurować nadmiarowość stref w oryginalnym regionie. Aby uzyskać szczegółowe instrukcje, zobacz Włączanie nadmiarowości strefowej na koncie Azure Cosmos DB.

W przypadku kont bezserwerowych należy włączyć nadmiarowość w strefach podczas zakładania konta.

Zachowanie, gdy wszystkie strefy są w dobrej kondycji

W tej sekcji opisano, czego można się spodziewać podczas konfigurowania konta Azure Cosmos DB dla strefowej nadmiarowości, gdy wszystkie strefy są operacyjne.

  • Cross-zone operation: Azure Cosmos DB automatycznie kieruje żądania do replik w różnych strefach dostępności, aby każda replika mogła obsłużyć żądanie.

  • Replikacja danych między strefami: Gdy klient wprowadza zmianę w dowolnych danych, ta zmiana jest stosowana do wielu replik w różnych strefach w celu osiągnięcia kworum. Takie podejście jest określane jako replikacja synchroniczna. Replikacja synchroniczna zapewnia wysoki poziom spójności danych, co zmniejsza prawdopodobieństwo utraty danych podczas awarii strefy. Strefy dostępności znajdują się stosunkowo blisko siebie, co oznacza minimalny wpływ na opóźnienie lub przepływność.

Zachowanie podczas awarii strefy

W tej sekcji opisano, czego można oczekiwać podczas konfigurowania konta Azure Cosmos DB z redundancją strefową i wystąpienia awarii w jednej ze stref.

  • Wykrywanie i odpowiedź: Platforma Azure Cosmos DB jest odpowiedzialna za wykrywanie awarii w strefie dostępności. Nie musisz nic robić, aby zainicjować tryb failover strefy.

  • Active requests: Gdy strefa dostępności stanie się niedostępna, Azure Cosmos DB przerywa wszelkie żądania w toku połączone z replikami w strefie, której dotyczy problem, a aplikacja musi ponowić próbę wykonania tych żądań. Upewnij się, że aplikacja jest przygotowana, postępując zgodnie ze wskazówkami dotyczącymi obsługi błędów przejściowych.

  • Oczekiwana utrata danych: Brak oczekiwanej utraty danych z powodu awarii strefy.

  • Oczekiwany przestój: Podczas przestojów w strefach połączenia mogą wystąpić krótkie przerwy, które zwykle trwają kilka sekund, ponieważ ruch jest redystrybuowany. Upewnij się, że aplikacje są przygotowane, postępując zgodnie ze wskazówkami dotyczącymi obsługi błędów przejściowych.

  • Redistribution: Azure Cosmos DB automatycznie przekierowuje przychodzące żądania do w pełni sprawnych replik w innych strefach dostępności. Gdy strefa dostępności ma awarię, platforma automatycznie przydziela aprowizowaną przepływność innym replikom.

Odzyskiwanie strefy

Gdy strefa dostępności zostanie odzyskana, Azure Cosmos DB automatycznie przywraca repliki w strefie dostępności i przekierowuje ruch między replikami w normalny sposób.

Testowanie pod kątem niepowodzeń strefy

Przełączanie awaryjne i odzyskiwanie strefy dostępności dla Azure Cosmos DB są całkowicie zarządzane przez Microsoft. Nie musisz inicjować ani weryfikować procesów awarii strefy dostępności.

Odporność na awarie całego regionu

Podczas wdrażania konta Azure Cosmos DB w jednym regionie awaria obejmująca cały region, która ma wpływ na wszystkie węzły Azure Cosmos DB, zwykle nie powoduje utraty danych, ale uniemożliwia aplikacji uzyskiwanie dostępu do danych. Azure Cosmos DB przywraca dostęp do danych po odzyskaniu usługi w danym regionie. Utrata danych występuje tylko wtedy, gdy region doświadcza nieodwracalnej awarii.

Aby przygotować się do rzadkich przypadków awarii regionów, można skonfigurować Azure Cosmos DB w celu obsługi różnych poziomów trwałości i dostępności przy użyciu jednego z następujących podejść:

Poniższa tabela zawiera podsumowanie dostępnych opcji odzyskiwania na podstawie konfiguracji konta i typu awarii. W kolejnych sekcjach tego artykułu przedstawiono szczegółowe informacje o tych opcjach i skojarzonym zachowaniu.

Configuration Typ awarii Wpływ na dostępność Wpływ trwałości Co zrobić
Konto jednoregionowe Awaria w regionie Dostęp do odczytu i zapisu zostanie utracony do czasu przywrócenia usługi. Brak utraty danych, chyba że region doświadcza nieodwracalnej awarii. Poczekaj na przywrócenie usługi lub zażądaj przywrócenia konta z kopii zapasowej do innego regionu.
Region pojedynczego zapisu, konto wielu regionów Awaria regionu odczytu SDK przekierowuje do dostępnych regionów na podstawie konfiguracji preferowanych regionów.

W przypadku kont korzystających z silnej spójności tylko z dwoma regionami lub gdy ograniczona nieaktualność przekracza okno nieaktualności, dostępność zapisu również zostanie utracona, chyba że włączysz tryb offline dla objętego regionu.		 Brak utraty danych. Zapewnij wystarczającą przepływność w pozostałych regionach. W przypadku spójności silnej lub ograniczonej stalości rozważ wyłączenie objętego regionu.
Region pojedynczego zapisu, konto wielu regionów Awaria w regionie zapisu (z włączonym programem PPAF) Automatyczne przechodzenie w tryb failover na poziomie partycji; nie jest wymagana interwencja ręczna. Jeśli konto używa silnej spójności, nie występuje utrata danych. Jeśli konto nie używa silnej spójności, niereplikowane dane mogą zostać utracone w mało prawdopodobnym przypadku, w którym region ulegnie trwałej utracie danych. Nie jest wymagana żadna akcja. PpAF automatycznie zarządza trybem failover.
Region pojedynczego zapisu, konto wielu regionów Awaria w regionie zapisu (bez protokołu PPAF) Utrata dostępności zapisu będzie występować do czasu zakończenia operacji wyłączenia regionu lub awaryjnego przełączenia zarządzanego przez usługę. Odczyty są kontynuowane z regionów w dobrej kondycji. Jeśli konto używa silnej spójności, dane nie są tracone. Jeśli konto nie używa silnej spójności, niereplikowane dane mogą zostać utracone w mało prawdopodobnym przypadku, w którym region ulegnie trwałej utracie danych. Wykonaj operację w trybie offline w regionie. Jeśli tryb failover zarządzany przez usługę jest włączony, Azure Cosmos DB automatycznie inicjuje tryb failover, ale może to potrwać co najmniej godzinę. Nie zmieniaj regionu zapisu podczas przestoju.
Konto regionu wielokrotnego zapisu Każde opóźnienie w regionie Automatyczne trasowanie do regionów w dobrej kondycji poprzez konfigurację SDK; nie wymaga ręcznej interwencji. Ostatnio zaktualizowane dane w regionie, który zakończył się niepowodzeniem, mogą być niedostępne w pozostałych regionach. W mało prawdopodobnym przypadku, gdy region cierpi na trwałą utratę danych, niereplikowane dane mogą zostać utracone. Zapewnij wystarczającą przepływność w pozostałych regionach. Po odzyskaniu Azure Cosmos DB automatycznie odzyskuje niereplikowane dane używając skonfigurowanej metody rozwiązywania konfliktów.
Dowolna konfiguracja konta Uszkodzenie lub przypadkowe usunięcie danych Brak wpływu na dostępność. Potencjalna utrata danych w zależności od tego, kiedy zostanie wykryte uszkodzenie lub usunięcie. Przywracanie według punktu w czasie (ciągła kopia zapasowa) lub przywracanie z okresowych kopii zapasowych.

Note

Ten artykuł koncentruje się na aspektach niezawodności funkcji Azure Cosmos DB w wielu regionach. Istnieją inne korzyści dla wielu regionów odczytu i zapisu, takich jak wyższa wydajność i skala dla aplikacji rozproszonych globalnie. Należy ocenić całą architekturę rozwiązania i wziąć pod uwagę wszystkie korzyści wynikające z korzystania z tych funkcji.

Zestawy SDK i odporność systemu

Zestawy SDK Azure Cosmos DB są ważną częścią strategii odporności aplikacji. Jeśli masz konto z wieloma regionami, konfiguracja SDK wpływa na sposób kierowania żądań między regionami, w tym preferowane regiony do nawiązania połączenia oraz regiony, które powinny być wykluczone. SDK monitorują dostępność regionów i partycji oraz mogą dynamicznie się rekonfigurować, aby używać zdrowych regionów i partycji, na przykład poprzez wyłącznik na poziomie partycji.

Aby uzyskać więcej informacji na temat obsługi wysokiej dostępności zestawu SDK, zobacz dokumentację dotyczącą wysokiej dostępności dla używanego zestawu SDK:

Potencjalna utrata danych podczas awarii regionów

Podczas wdrażania konta 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 celu punktu odzyskiwania (RPO) dla wszystkich poziomów spójności w przypadku konta Azure Cosmos DB, które jest wdrożone w co najmniej dwóch regionach. RPO reprezentuje potencjalną utratę danych podczas przerwy w dostępności regionu.

Poziom spójności Odzyskiwanie punktu docelowego (RPO) dla awarii w regionie
Sesja, spójny prefiks, ostateczna Mniej niż 15 minut
Ograniczona nieaktualność K i T
Mocny 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.

Wiele regionów odczytu z jednym regionem zapisu

Jeśli rozwiązanie wymaga nieprzerwanej dostępności na wypadek przestojów w regionie, możesz skonfigurować Azure Cosmos DB, aby replikować dane w wielu regionach, z zapisami wykonywanymi w regionie podstawowym. Opcjonalnie możesz skonfigurować aplikacje tak, aby łączyć się z określonymi regionami odczytu, co może pomóc w poprawie wydajności. Jeśli region ma awarię, konto może nadal działać z regionów w dobrej kondycji.

Diagram przedstawiający konto Azure Cosmos DB. Region A to region zapisu i odczytu, a region B to region odczytu. Aplikacja w regionie A wykonuje operacje odczytu i zapisu względem konta Azure Cosmos DB w regionie A. Aplikacja w regionie B wykonuje operacje odczytu względem konta w regionie B, ale zapisuje w regionie A. Wewnętrznie Azure Cosmos DB replikuje zmiany między regionami.

Przechodzenie na tryb awaryjny między regionami

Zestaw SDK Azure Cosmos DB można skonfigurować z priorytetową listą regionów odczytu. Zestaw SDK łączy aplikację z pierwszym dostępnym regionem na liście. Podczas awarii regionu odczytu zestaw SDK wykrywa awarię regionu za pośrednictwem kodów odpowiedzi zaplecza, oznacza je jako niedostępne i kieruje przyszłe operacje do następnego dostępnego regionu na liście preferencji. Upewnij się, że lista preferowanych regionów jest poprawnie ustawiona i zgodna z wymaganiami biznesowymi oraz wymaganiami dotyczącymi opóźnień. Aby uzyskać szczegółowe wskazówki, zobacz Rozwiązywanie problemów z dostępnością zestawu SDK usługi Azure Cosmos DB.

Proces failover polega na sprawieniu, że jeden z regionów twojego konta stanie się niedostępny, w całości lub częściowo. Wpływ przejścia w tryb failover zależy od tego, czy region jest regionem zapisu, czy regionem odczytu:

  • Jeśli region zapisu stanie się niedostępny, inny region stanie się regionem zapisu.
  • Jeśli region odczytu stanie się niedostępny, ten region nie może obsłużyć żądań odczytu, a inne regiony są używane do operacji odczytu.

Azure Cosmos DB zapewnia wiele typów trybu failover:

  • Automatyczne przełączanie awaryjne dla partycji (PPAF): Wewnętrznie Azure Cosmos DB rozkłada dane na wiele partycji fizycznych. Jeśli wystąpi problem z infrastrukturą obsługującą partycję, inne partycje mogą nie mieć wpływu. PPAF umożliwia automatyczne przełączanie pojedynczych partycji do regionu pomocniczego, podczas gdy zdrowe partycje pozostają w regionie podstawowym. PPAF może pomóc zminimalizować przestoje i umożliwić szybsze odzyskiwanie podczas awarii w części regionu. Aby uzyskać więcej informacji, zobacz Jak rozpocząć i wdrożyć Automatyczne przełączanie w trybie failover dla każdej partycji (PPAF) dla Azure Cosmos DB.

    Note

    Automatyczne przełączanie na tryb failover dla partycji jest dostępne w publicznej wersji zapoznawczej. Ta funkcja jest udostępniana bez umowy dotyczącej poziomu usług. Aby uzyskać więcej informacji, zobacz Warunki dodatkowe korzystania z testowych wersji Microsoft Azure.

  • Wymuszone przejście w tryb failover: Możesz przejąć jeden z regionów konta w trybie offline. Jest to również nazywane operacją trybu failover zarządzaną przez klienta lub operacją w regionie offline . Jest to zalecane podejście do szybkiego przywracania dostępności podczas awarii. Odpowiadasz za wykrywanie awarii i wyzwalanie trybu failover. Możesz również użyć wymuszonego przełączenia awaryjnego, aby symulować scenariusze awarii w regionie na potrzeby testowania, na przykład podczas symulacji odzyskiwania po awarii.

    Jeśli przełączysz region zapisu do trybu offline, region odczytu z następnym najwyższym priorytetem stanie się nowym regionem zapisu. Jeśli przełączysz region odczytu do trybu offline, aplikacje będą mogły łączyć się z dowolnym innym regionem odczytu na koncie.

    Wymuszone przejście w tryb failover w regionie zapisu może prowadzić do utraty danych w przypadku niereplikowanych zapisów.

    Po wymuszonym awaryjnym przełączeniu Microsoft musi przywrócić region do działania online. W przypadku regionów w dobrej kondycji ten proces jest zautomatyzowany, ale może potrwać do kilku dni. Jeśli region nie wróci do trybu online w ciągu dnia lub dwóch, otwórz zgłoszenie do pomocy technicznej, aby poprosić o pomoc.

  • Zmień region zapisu: Gdy regiony są w dobrej kondycji, możesz zmienić region zapisu konta. Ta zmiana jest w rzeczywistości planowanym przełączeniem awaryjnym regionu zapisu dla twojego konta.

    Zmiana regionu zapisu nie powoduje utraty danych, ponieważ replikacja danych nadrabia zaległość przed podwyższeniem poziomu nowego regionu zapisu. Może wystąpić krótka przerwa, ale klienci korzystający z logiki ponawiania prób i innych czasowych technik obsługi błędów zwykle nie odczuwają znaczącego wpływu.

    Ta operacja wymaga, aby regiony były w dobrej kondycji, więc nie można jej używać podczas awarii regionu.

  • Zarządzanie awariami przez usługę: Gdy konto korzysta z zarządzania awariami przez usługę, Microsoft jest odpowiedzialny za podjęcie decyzji o tym, kiedy należy przełączać na tryb awaryjny między regionami. Aby włączyć tryb failover zarządzany przez usługę, należy określić priorytety dla każdego regionu. Jednak proces deklarowania awarii i wyzwalania trybu failover zarządzanego przez usługę może zająć dużo czasu — potencjalnie jedną godzinę lub więcej. Aby przyspieszyć odzyskiwanie, wykonaj wymuszone przejście w tryb failover zamiast czekać na wyzwolenie trybu failover zarządzanego przez usługę.

    Jeśli Microsoft uruchomi tryb failover zarządzany przez usługę dla regionu zapisu konta, mogą zostać utracone wszelkie zapisy, które nie zostały zreplikowane.

    Po awarii zarządzanej przez usługę, Microsoft musi przywrócić region do trybu online. Microsoft automatycznie przenosi region do trybu online, ale ten proces może potrwać kilka dni.

Requirements

Region support: Możesz skonfigurować dowolny region Azure jako region odczytu dla konta Azure Cosmos DB.

Koszt

Dodanie dodatkowego regionu odczytu do konta Azure Cosmos DB zwiększa istniejące koszty dla każdego regionu. Aby uzyskać więcej informacji, zobacz Cennik usługi Azure Cosmos DB.

Konfigurowanie wielu regionów odczytu

Planowanie pojemności i zarządzanie nimi

Jeśli aplikacja rozpowszechnia żądania między regionami, a jeden region przejdzie w tryb offline, pozostałe regiony będą doświadczać większego woluminu żądań. Użyj autoskalowania przepustowości, aby dynamicznie dostosowywać zasoby zgodnie z zapotrzebowaniem. Jeśli używasz przepustowości z przydziałem zasobów, zaplanuj odpowiednią pojemność, aby obsłużyć utratę dostępu do regionu bez pogorszenia jakości usług i rozważ nadprzydzielanie zasobów. Aby uzyskać więcej informacji, zobacz Zarządzanie pojemnością za pomocą nadmiernej aprowizacji.

Zachowanie, gdy wszystkie regiony są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać podczas konfigurowania konta Azure Cosmos DB z wieloma regionami odczytu, a wszystkie regiony działają.

Zachowanie podczas niepowodzenia regionu odczytu

W tej sekcji opisano, czego można oczekiwać podczas konfigurowania konta Azure Cosmos DB z wieloma regionami odczytu i awarii w jednym z regionów odczytu konta.

Important

W idealnym przypadku awarie regionów odczytu powinny być obsługiwane na poziomie klienta przez prawidłowe skonfigurowanie listy preferowanych regionów w konfiguracji zestawu SDK. Po poprawnym skonfigurowaniu zestaw SDK automatycznie wykrywa awarię i przekierowuje operacje odczytu do następnego dostępnego regionu bez konieczności przechodzenia w tryb failover po stronie usługi.

  • Wykrywanie i reagowanie: Odpowiedzialność za wykrywanie awarii i reagowania zależy od typu trybu failover używanego konta.

    • PPAF: PpAF zwykle nie dotyczy awarii regionów odczytu. Jednak w przypadku kont o silnej spójności i tylko dwóch regionach utrata regionu odczytu zmniejsza konto do jednego regionu, który nie może obsługiwać dynamicznego kworum. W tym scenariuszu PPAF może aktywować, aby zachować dostępność, przenosząc dotknięte partycje do nieuszkodzonego regionu.

    • Wymuszone przełączenie: Odpowiadasz za wykonanie wymuszonego przełączenia. Aby uzyskać szczegółowe instrukcje, zobacz Wykonaj wymuszone przełączenie w tryb failover dla konta Azure Cosmos DB.

      Jeśli nie przeprowadzisz przełączenia awaryjnego, zachowanie konta zależy od poziomu spójności:

      • Silna spójność: silna spójność wymaga co najmniej dwóch regionów do utrzymania dynamicznego kworum. Jeśli dostępne są mniej niż dwa regiony i nie przeprowadzasz przełączenia awaryjnego, konto utraci możliwość zapisu do momentu przywrócenia usługi.

      • Spójność ograniczonej nieaktualności: Spójność ograniczonej nieaktualności opiera się na utrzymaniu określonego progu nieaktualności między regionami. Jeśli długość awarii regionu przekroczy próg, system nie może zachować spójności między zapisami. Jeśli nie wykonasz przełączenia awaryjnego, konto utraci możliwość zapisu aż do przywrócenia usługi.

    • Tryb failover zarządzany przez usługę: Jeśli tryb failover zarządzany przez usługę jest włączony, Microsoft ostatecznie wykryje awarię i zainicjuje przejście w tryb failover konta. Jednak ten proces może zająć dużo czasu, potencjalnie jedną godzinę lub więcej. Aby przyspieszyć odzyskiwanie, wykonaj wymuszone przejście w tryb failover zamiast czekać na wyzwolenie trybu failover zarządzanego przez usługę.

  • Aktywne żądania: Każde aktywne żądanie może zostać zakończone i klient będzie musiał je ponowić po zakończeniu procesu failover. Jeśli klienci odpowiednio obsługują błędy przejściowe, ponawiając próbę po krótkim czasie, zwykle unikają znaczącego wpływu.

  • Oczekiwana utrata danych: Awaria w regionie odczytu nie powoduje utraty danych. Azure Cosmos DB nadal przestrzega gwarancji spójności odczytu.

  • Oczekiwany przestój: Ilość przestojów, z których korzysta Twoje konto, zależy od typu trybu failover używanego przez konto.

    • PPAF: Po włączeniu ppAF system automatycznie wykrywa i odzyskuje dane po awarii, zazwyczaj w ciągu 3 minut, bez żadnej interwencji ręcznej.

    • Wymuszone przejście w tryb failover: Przestój zależy od:

      • Jak długo trwa odnajdywanie awarii i inicjowanie trybu failover.

      • Jak długo trwa przejście w tryb failover, czyli zwykle kilka sekund.

        Warning

        Nie wykonuj żadnych operacji konfiguracji (płaszczyzny sterowania) w danym regionie podczas scenariuszy awarii, ponieważ powodują one niespójność kont i opóźnienie odzyskiwania. Przykłady niektórych operacji płaszczyzny sterowania, których uniknąć należy, obejmują:

        • Zmienianie regionu zapisu lub modyfikowanie priorytetu trybu failover
        • Zaktualizuj konto do konfiguracji z obsługą wielu zapisów
        • Aktualizowanie poziomów spójności lub innych ustawień konta
        • Aktualizowanie konfiguracji prywatnego punktu końcowego lub ustawień sieci
        • Aktualizowanie przepływności konta lub operacji skalowania
        • Każda inna operacja, która modyfikuje ustawienia konfiguracji konta lub regionu

    • Zarządzany przez usługę tryb failover: Microsoft jest odpowiedzialny za inicjowanie zarządzanego przez usługę trybu failover, a przestój środowiska konta zależy od czasu zadeklarowania awarii przez Microsoft i zainicjowania trybu failover. W niektórych sytuacjach może upłynąć co najmniej jedna godzina. Jeśli na twoim koncie wystąpią zakłócenia zapisu i musisz szybko przywrócić dostępność zapisu, wykonaj wymuszone przejście w tryb failover.

  • Redystrybucja: W przypadku wymuszonego awaryjnego przełączania lub awaryjnego przełączania zarządzanego usługowo region, którego dotyczy problem, jest odłączony i oznaczony jako tryb offline.

    W kodzie aplikacji nie są wymagane żadne zmiany w celu obsługi awarii regionów odczytu. Zestawy SDK Azure Cosmos DB przekierowują operacje 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, operacje odczytu automatycznie wracają do bieżącego regionu zapisu konta zgodnie z konfiguracją w usłudze.

    Note

    Jeśli używasz prywatnych punktów końcowych z kontem Azure Cosmos DB, upewnij się, że prywatny DNS poprawnie rutuje po przeprowadzeniu operacji regionu w trybie offline. Aby uzyskać szczegółowe wskazówki, zobacz Kwestie dotyczące przełączania awaryjnego dla prywatnych punktów końcowych.

Zachowanie podczas awarii regionu zapisu

W tej sekcji opisano, czego można oczekiwać podczas konfigurowania konta Azure Cosmos DB z wieloma regionami odczytu, a w regionie zapisu konta występuje awaria.

  • Wykrywanie i reagowanie: Odpowiedzialność za wykrywanie awarii i reagowania zależy od typu trybu failover używanego konta.

    • PPAF: Microsoft automatycznie wykrywa awarię i w razie potrzeby inicjuje przejście w tryb failover niektórych partycji. Aplikacja nie musi podejmować żadnych działań.

    • Wymuszone awaryjne przełączenie: Odpowiadasz za wykonanie wymuszonego awaryjnego przełączenia. Aby uzyskać szczegółowe instrukcje, zobacz Wykonaj wymuszone przełączenie awaryjne dla konta Azure Cosmos DB.

      Jeśli nie wykonasz przełączenia awaryjnego, konto straci możliwość zapisu do momentu przywrócenia usługi.

      Jeśli wystąpi awaria regionu zapisu konta, unikaj wykonywania operacji zmiany regionu zapisu. Zmiany w regionie zapisu nie powiedzie się, jeśli wystąpi awaria regionu źródłowego lub docelowego. Przyczyną jest to, że procedura zmiany regionu obejmuje sprawdzanie spójności, które wymaga łączności między regionami.

    • Przełączenie awaryjne zarządzane przez usługę: Microsoft automatycznie wykrywa awarię i inicjuje przełączenie awaryjne konta. Aplikacja nie musi podejmować żadnych działań.

  • Aktywne żądania: Po zakończeniu procesu przełączenia awaryjnego wszystkie aktywne żądania mogą zostać zakończone i klient musi je ponowić. Jeśli klienci odpowiednio obsługują błędy przejściowe, ponawiając próbę po krótkim czasie, zwykle unikają znaczącego wpływu.

  • Oczekiwana utrata danych: Jeśli skonfigurujesz konto z silną spójnością, nie wystąpi żadna utrata danych. W przeciwnym razie wszelkie niereplikowane zapisy mogą zostać utracone po zakończeniu procesu przełączenia awaryjnego. Aby uzyskać informacje o maksymalnej utracie danych oczekiwanej podczas przestoju w regionie, zobacz Potencjalna utrata danych podczas przestojów regionów.

  • Oczekiwany przestój: Ilość przestojów, z których korzysta Twoje konto, zależy od typu trybu failover używanego przez konto.

    • PPAF: Po włączeniu PPAF należy spodziewać się krótkiej przerwy, która zwykle wynosi około 3 minut.

    • Wymuszone przełączenie awaryjne: Przestój zależy od:

      • Jak długo trwa odnajdywanie awarii i inicjowanie trybu failover.
      • Jak długo trwa przejście w tryb failover, czyli zwykle kilka sekund.

    Warning

    Nie wykonuj żadnych operacji płaszczyzny sterowania w danym regionie podczas scenariuszy awarii, ponieważ powodują one niespójności w koncie i opóźnienie procesu odzyskiwania. Przykłady niektórych operacji płaszczyzny sterowania, których uniknąć należy, obejmują:

    • Zmiana regionu zapisu lub modyfikacja priorytetu przełączenia awaryjnego
    • Zaktualizuj konto do konfiguracji z obsługą wielu zapisów
    • Aktualizowanie poziomów spójności lub innych ustawień konta
    • Aktualizowanie konfiguracji prywatnego punktu końcowego lub ustawień sieci
    • Aktualizowanie przepływności konta lub operacji skalowania
    • Każda inna operacja, która modyfikuje ustawienia konfiguracji konta lub regionu
    • Zarządzany przez usługę tryb failover: Microsoft jest odpowiedzialny za inicjowanie zarządzanego przez usługę trybu failover, a przestój konta zależy od czasu potrzebnego na zadeklarowanie awarii i zainicjowanie trybu failover przez Microsoft. W niektórych sytuacjach może upłynąć co najmniej jedna godzina. Aby szybko przywrócić dostępność zapisu, wykonaj wymuszone przełączenie awaryjne.

  • Redystrybucja: Redystrybucja ruchu zapisu zależy od typu przełączania awaryjnego używanego przez konto.

    • PPAF: Azure Cosmos DB automatycznie przełącza partycję w złej kondycji do zdrowego regionu.

    • Wymuszone przełączenie: Gdy wykonujesz wymuszone przełączenie, region zapisu twojego konta zmienia się na region, który określisz.

    Note

    Jeśli używasz prywatnych punktów końcowych z kontem Azure Cosmos DB, upewnij się, że prywatny DNS poprawnie rutuje po przeprowadzeniu operacji regionu w trybie offline. Aby uzyskać szczegółowe wskazówki, zobacz Kwestie dotyczące przełączania awaryjnego dla prywatnych punktów końcowych.

    • Automatyczne przełączenie zarządzane przez usługę: Azure Cosmos DB automatycznie promuje jeden z pomocniczych regionów konta na nowy główny region zapisu. Przejście w tryb failover odbywa się do innego regionu w kolejności priorytetu regionu, który określasz.

Odzyskiwanie regionów

Microsoft musi przywrócić region do trybu online. Gdy region zostanie odzyskany po awarii, Microsoft automatycznie przełączy region do trybu online. Jednak ten proces może potrwać kilka dni.

Important

Po wymuszonym przejściu w tryb failover Microsoft automatycznie przywraca region do trybu online dla regionów w dobrej kondycji. Jeśli region nie wróci do trybu online w ciągu dnia lub dwóch, otwórz zgłoszenie do pomocy technicznej, aby poprosić o pomoc.

Kiedy region jest online, podejmowane działania różnią się w zależności od tego, czy awaria była w regionie odczytu, czy w regionie zapisu.

  • Po awarii regionu odczytu: Gdy region, 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 pełnym 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.

  • Po przerwie w dostępności regionu zapisu: Gdy region, którego dotyczy problem, ponownie jest w trybie online, pojawia się jako "online" w portalu Azure i staje się dostępny jako region do czytania. W tym momencie można bezpiecznie zmienić region zapisu z powrotem do odzyskanego regionu.

    Important

    Odzyskany region nie zostanie automatycznie z powrotem podwyższony jako region zapisu po odzyskaniu. Twoim zadaniem jest powrót do odzyskanego regionu jako regionu zapisu, gdy będzie to bezpieczne.

    Nie występują żadne utraty danych ani dostępności przed, w trakcie ani po zmianie regionu zapisu. Aplikacja nadal jest wysoce dostępna.

    Jeśli jakiekolwiek zapisy nie zostały zreplikowane przed przejściem regionu do trybu offline, możesz odczytać niereplikowane zapisy ze źródła danych konfliktów. Aplikacja może odczytywać zestawienie konfliktów, rozwiązywać wszelkie konflikty na podstawie logiki specyficznej dla aplikacji i zapisywać zaktualizowane dane z powrotem do kontenera zgodnie z potrzebami.

Testowanie pod kątem błędów regionów

Aplikacja może nie obsługiwać prawidłowo awarii regionalnych, nawet jeśli konto Azure Cosmos DB charakteryzuje się wysoką dostępnością. 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 wymuszony tryb failover przy użyciu programu PowerShell, Azure CLI lub portalu Azure, a następnie monitoruj aplikację. Po zakończeniu testu możesz przywrócić działanie w regionie podstawowym, gdy region automatycznie wróci do trybu online, a następnie przywrócić zarządzane przez usługę przełączanie awaryjne dla konta. Jeśli region nie wróci do trybu online w ciągu dnia lub dwóch, otwórz zgłoszenie do pomocy technicznej, aby poprosić o pomoc.

Jeśli konto korzysta z PPAF, możesz zasymulować awarię partycji. Aby uzyskać więcej informacji, zobacz Testowanie konfiguracji ppAF (symulowanie błędu).

Wiele regionów zapisu

Usługę Azure Cosmos DB można skonfigurować tak, aby akceptowała zapisy w wielu regionach. Ta konfiguracja może zapewnić bardzo wysoką odporność na przerwy w działaniu regionów. Jest to również przydatne w przypadku zmniejszenia opóźnienia zapisu w aplikacjach rozproszonych geograficznie.

Diagram przedstawiający konto Azure Cosmos DB. Region A i region B to regiony zapisu i odczytu. Aplikacja w regionie A wykonuje operacje odczytu i zapisu względem konta Azure Cosmos DB w regionie A. Aplikacja w regionie B wykonuje operacje odczytu i zapisu względem konta Azure Cosmos DB w regionie B. Wewnętrznie Azure Cosmos DB asynchronicznie replikuje zmiany między regionami.

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. Region centrum działa jako arbiter w konfliktach 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 jest, aby wziąć pod uwagę projekt aplikacji oraz to, jak działa ona z wieloma regionami zapisu. Zapoznaj się z najlepszymi rozwiązaniami dotyczącymi zapisów w wielu regionach.

Requirements

Region support: Możesz skonfigurować dowolny region Azure jako region odczytu lub zapisu dla konta Azure Cosmos DB.

Koszt

Dodanie dodatkowego regionu zapisu do konta Azure Cosmos DB zwiększa istniejące koszty dla każdego regionu. Aby uzyskać więcej informacji, zobacz Cennik usługi Azure Cosmos DB.

Konfigurowanie wielu regionów zapisu

Możesz skonfigurować wiele regionów zapisu na koncie podczas tworzenia konta lub w dowolnym momencie po utworzeniu konta. Aby uzyskać więcej informacji, zobacz Konfigurowanie wielu regionów zapisu.

Aby efektywnie korzystać z wielu regionów zapisu, aplikacja musi być również odpowiednio skonfigurowana. Zobacz Konfigurowanie zapisów w wielu regionach w aplikacjach używających Azure Cosmos DB.

Planowanie pojemności i zarządzanie nimi

Jeśli aplikacja rozpowszechnia żądania między regionami, a jeden region przejdzie w tryb offline, pozostałe regiony będą doświadczać większego woluminu żądań. Użyj autoskalowania przepustowości, aby dynamicznie dostosowywać zasoby zgodnie z zapotrzebowaniem. Jeśli używasz przepustowości z przydziałem zasobów, zaplanuj odpowiednią pojemność, aby obsłużyć utratę dostępu do regionu bez pogorszenia jakości usług i rozważ nadprzydzielanie zasobów. Aby uzyskać więcej informacji, zobacz Zarządzanie pojemnością za pomocą nadmiernej aprowizacji.

Zachowanie, gdy wszystkie regiony są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać podczas konfigurowania konta Azure Cosmos DB z wieloma regionami zapisu, a wszystkie regiony działają.

Zachowanie podczas awarii regionu

W tej sekcji opisano, czego można oczekiwać podczas konfigurowania konta Azure Cosmos DB z wieloma regionami zapisu, a w jednym z regionów odczytu lub zapisu konta występuje awaria.

  • Wykrywanie i reagowanie: Aplikacja wykrywa utratę regionu. zestawy SDK Azure Cosmos DB zapewniają automatyczne możliwości wyboru regionów, które kierują operacje odczytu i zapisu do regionów w dobrej kondycji.

  • Aktywne żądania: Każde aktywne żądanie może zostać zakończone i trzeba je będzie ponowić przez klienta po zakończeniu przełączenia awaryjnego. Jeśli klienci odpowiednio obsługują błędy przejściowe, ponawiając próbę po krótkim czasie, zwykle unikają znaczącego wpływu.

  • Oczekiwana utrata danych: Ostatnio zaktualizowane dane mogą stać się niedostępne w innych regionach. Aby uzyskać informacje o maksymalnej utracie danych oczekiwanej podczas przestoju w regionie, zobacz Potencjalna utrata danych podczas przestojów regionów. W mało prawdopodobnym przypadku, gdy region, którego dotyczy problem, ulegnie trwałej utracie danych, możesz utracić niereplikowane dane.

  • Oczekiwany przestój: Nie ma oczekiwanego przestoju w konfiguracjach z wieloma zapisami, pod warunkiem, że zestawy SDK są poprawnie skonfigurowane za pomocą ApplicationRegions lub PreferredRegions.

    Wskazówka

    Aby uzyskać najlepsze wyniki, aplikacje rozproszone globalnie powinny być frontowane przez globalną usługę równoważenia obciążenia, taką jak Azure Front Door lub Azure Traffic Manager. Te usługi mogą wykrywać degradację regionalną i automatycznie kierować ruch do instancji aplikacji w regionie w dobrej kondycji.

  • Redistribution: Zestawy SDK Azure Cosmos DB automatycznie wykrywają, że region jest w złej kondycji i przekierowuje operacje odczytu i zapisu do następnego dostępnego regionu na liście preferowanych regionów. W kodzie aplikacji nie są wymagane żadne zmiany.

    Wskazówka

    Jeśli aplikacja jest frontowana przez usługę Azure Front Door lub Traffic Manager, te usługi wykrywają również degradację regionalną i kierują ruch do regionu w dobrej kondycji.

Odzyskiwanie regionów

Gdy region, którego dotyczy problem, wróci do trybu online, region będzie wyświetlany jako "online" w portalu Azure i stanie się dostępny ponownie.

Wszystkie dane zapisu, które nie zostały zreplikowane w momencie awarii regionu, zostaną udostępnione za pośrednictwem kanału konfliktowego. 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.

Testowanie pod kątem błędów regionów

Aby przetestować scenariusze awaryjnego przełączania zapisu w wielu regionach, możesz wyłączyć region zapisu przy użyciu wymuszonego przełączenia awaryjnego. Ten proces symuluje awarię regionu i możesz zobaczyć, jak aplikacja reaguje.

Tworzenie kopii zapasowej i przywracanie

W przypadku większości rozwiązań nie należy polegać wyłącznie na kopiach zapasowych. Zamiast tego skorzystaj z innych możliwości opisanych w tym przewodniku, aby spełnić wymagania dotyczące odporności. Jednak kopie zapasowe chronią przed pewnymi zagrożeniami, których nie zapewniają inne podejścia. Aby uzyskać więcej informacji, zobacz Co to jest nadmiarowość, replikacja i kopia zapasowa?.

Utrata danych może wystąpić z powodu przypadkowego usunięcia lub innych problemów w aplikacji, które powodują uszkodzenie danych. W przypadku korzystania z konta z jednym regionem utrata danych może również wystąpić z powodu nieodwracalnej awarii w regionie Azure Cosmos DB. Aby ułatwić ochronę przed utratą danych, Azure Cosmos DB zapewnia zestaw funkcji tworzenia kopii zapasowych i przywracania. Kopie zapasowe i przechowywanie można skonfigurować na podstawie wymagań dotyczących możliwości odzyskiwania i wymagań dotyczących kosztów. Aby uzyskać więcej informacji, zobacz Online backup and on-demand data restore in Azure Cosmos DB (Tworzenie kopii zapasowych online i przywracanie danych na żądanie w usłudze Azure Cosmos DB).

Odporność usługi na prace konserwacyjne

Azure Cosmos DB przejrzyście zarządza wszystkimi szczegółami poszczególnych węzłów obliczeniowych i automatycznie wykonuje aktualizacje oraz inne typy planowanych prac konserwacyjnych. Umowy SLA Azure Cosmos DB dotyczące dostępności i opóźnień mają zastosowanie do wszystkich wykonywanych przez system operacji konserwacji automatycznej.

Umowa dotycząca poziomu usług

Umowa dotycząca poziomu usług (SLA) dla usług platformy Azure opisuje oczekiwaną dostępność każdej usługi oraz warunki, które rozwiązanie musi spełnić, aby osiągnąć te oczekiwania dotyczące dostępności. Aby uzyskać więcej informacji, zobacz Umowy SLA dotyczące usług online.

Azure Cosmos DB zapewnia umowy SLA dla różnych konfiguracji i cech usługi, w tym dostępności, opóźnienia, przepływności i spójności.

Umowy SLA dotyczące dostępności różnią się w zależności od tego, czy są używane jakiekolwiek z następujących możliwości produktu:

  • Aprowizowana przepływność
  • Konto jednoregionowe z obsługą strefy dostępności (nadmiarowość strefy)
  • Konta korzystające z wielu regionów odczytu
  • Konta korzystające z wielu regionów zapisu (warstwa Krytyczne dla działania firmy)

Treści powiązane

  • Last updated on