Niezawodność w usłudze Azure DocumentDB

Azure DocumentDB to w pełni zarządzana usługa bazy danych NoSQL na potrzeby nowoczesnego tworzenia aplikacji ze zgodnością z bazą danych MongoDB. Azure DocumentDB obsługuje konfigurację wysokiej dostępności (HA) z synchronicznie replikowanymi replikami w trybie hot standby oraz nadmiarowością stref. Zapewnia również opcjonalną replikę tylko do odczytu w innym regionie Azure oraz automatyczne kopie zapasowe z możliwością przywracania do określonego momentu w celu ochrony przed przypadkową utratą 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 documentDB 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. Opisuje również sposób działania kopii zapasowych i zawiera kluczowe informacje o wysokiej dostępności oraz replikacji między regionami.

Zalecenia dotyczące wdrażania produkcyjnego pod kątem niezawodności

Aby uzyskać listę zaleceń dotyczących poprawy niezawodności klastra, zobacz Najlepsze rozwiązania dotyczące wysokiej dostępności i replikacji między regionami w usłudze Azure DocumentDB.

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 jest klastrem usługi DocumentDB Azure. Dla każdego klastra należy wybrać warstwę obliczeniową i skonfigurować magazyn. Wybrana warstwa określa możliwości dostępne dla funkcji niezawodności, takich jak wysoka dostępność (HA), a także wpływa na sposób planowania pojemności na potrzeby scenariuszy odporności.

Aplikacje łączą się z klastrem przy użyciu parametrów połączenia i punktów końcowych. Usługa Azure DocumentDB zapewnia punkty końcowe do połączeń na potrzeby operacji odczytu i zapisu oraz, po odpowiednim skonfigurowaniu, punkty końcowe dla klastrów replik do odczytu. Te punkty końcowe pozwalają aplikacji nadal używać stabilnych wzorców połączeń, podczas gdy usługa zarządza zachowaniem trybu failover w tle.

W każdym klastrze dane są zorganizowane jako bazy danych, kolekcje i dokumenty. Ten model danych zgodny z bazą danych MongoDB jest podstawą decyzji projektowych na poziomie obciążenia, takich jak strategia fragmentowania, wzorce odczytu i zapisu oraz zakres tworzenia kopii zapasowych i przywracania.

Architektura fizyczna

Azure DocumentDB uruchamia klaster w oparciu o shardy, które reprezentują węzły (maszyny wirtualne), na których działa usługa. Można wdrożyć jeden fragment lub skalować w poziomie do wielu fragmentów. Zastosowanie wielu shardów zwiększa możliwości skalowania, ale samo w sobie nie zapewnia wysokiej dostępności.

Po włączeniu HA usługa Azure DocumentDB udostępnia odpowiadający zestaw fragmentów w trybie gotowości. Każdy główny odłamek ma zapasowy odłamek. Usługa replikuje dane synchronicznie między każdą parą rezerwową podstawową i promuje fragment rezerwowy, jeśli podstawowy fragment zakończy się niepowodzeniem. Aby uzyskać więcej informacji na temat wysokiej dostępności, zobacz Wysoka dostępność w usłudze Azure DocumentDB.

Azure DocumentDB używa usługi Azure Storage w celu zapewnienia trwałości odłamków. Jeśli HA jest wyłączone, każdy shard korzysta z pamięci masowej lokalnie nadmiarowej (LRS). LRS utrzymuje trzy kopie danych, ale nie jest odporne na utratę strefy dostępności. Informacje o trwałości LRS można znaleźć w artykule Podsumowanie opcji nadmiarowości.

Aby uzyskać więcej informacji, zobacz Dostępność i odzyskiwanie po awarii (DR) w usłudze Azure DocumentDB: Za kulisami.

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.

Azure DocumentDB jest zgodny z protokołem MongoDB, dlatego aplikacje zwykle łączą się przy użyciu sterowników bazy danych MongoDB. Odpowiadasz za skonfigurowanie ustawień ponawiania prób sterownika aplikacji w celu obsługi przejściowych błędów, zwłaszcza przerw w działaniu połączenia i krótkich przerw w zapisie podczas zdarzeń trybu failover. Postępuj zgodnie z tymi wytycznymi:

  • Użyj sterowników bazy danych MongoDB, które obsługują automatyczną obsługę ponawiania prób w przypadku przejściowych błędów łączności.

  • Skonfiguruj ponawianie prób przy użyciu wycofywania wykładniczego i ogranicz liczbę ponownych prób.

  • Jeśli to możliwe, należy zaprojektować operacje zapisu, aby były idempotentne, dzięki czemu ponawianie próby jest bezpieczne. Aby uzyskać ogólne wskazówki dotyczące implementacji dotyczące idempotentności, zobacz Wzorzec idempotentnego konsumenta.

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.

Aby użyć obsługi strefy dostępności w usłudze Azure DocumentDB, włącz wysoką dostępność. Po włączeniu HA w regionie obsługującym strefy dostępności klaster staje się nadmiarowy między strefami, ponieważ usługa Azure DocumentDB umieszcza fragmenty zapasowe w innej strefie dostępności niż ich fragmenty podstawowe. Shardy zapasowe nie odbierają żądań klientów, chyba że ich główny shard ulegnie awarii.

Jeśli wyłączysz HA, usługa Azure DocumentDB nie umieszcza fragmentów zapasowych w innej strefie dostępności, więc awaria strefy dostępności może spowodować niedostępność klastra.

Schemat klastra Azure DocumentDB z nadmiarowością strefową, z podstawowymi i rezerwowymi fragmentami danych w oddzielnych strefach dostępności.

Requirements

Zagadnienia do rozważenia

Chociaż niektóre interfejsy API usługi DocumentDB Azure zawierają odwołania do trybów wdrażania w tej samej strefie, Azure usługa DocumentDB nie obsługuje wdrożeń wysokiej dostępności w tej samej strefie. Usługa obsługuje wdrożenia wysokiej dostępności z nadmiarowością między strefami.

Dystrybucja wystąpień między strefami

Microsoft wybiera dwie strefy dostępności klastra. W wdrożeniach wysokiej dostępności z nadmiarowością strefową usługa Azure DocumentDB umieszcza wszystkie fragmenty podstawowe w jednej strefie, a wszystkie fragmenty w trybie gotowości w drugiej strefie.

Cost

Gdy funkcja HA jest włączona, usługa Azure DocumentDB aprowizuje zapasowy odłamek dla każdego podstawowego odłamka, co zwiększa koszty mocy obliczeniowej i magazynowania w klastrze. W regionach obsługujących strefy dostępności wysoka dostępność sprawia również, że strefa klastra jest strefowo nadmiarowa. W niektórych trybach wdrażania Azure DocumentDB domyślnie włącza wysoką dostępność. W przypadku obciążeń produkcyjnych pozostaw włączoną funkcję HA. W przypadku obciążeń programistycznych i testowych można wyłączyć wysoką dostępność (HA), aby obniżyć koszty. Aby uzyskać szczegółowe informacje o cenach, zobacz Azure Cennik usługi DocumentDB.

Konfiguruj obsługę stref dostępności

  • Utwórz nowy nadmiarowy strefowo klaster usługi Azure DocumentDB: Podczas tworzenia klastra w regionie obsługującym strefy dostępności włącz wysoką dostępność, aby klaster był nadmiarowy strefowo. Aby uzyskać szczegółowe instrukcje, zobacz Szybki start: tworzenie klastra usługi DocumentDB Azure przy użyciu portalu Azure.

  • Włącz nadmiarowość strefową w istniejącym klastrze usługi Azure DocumentDB: W istniejącym klastrze można włączyć wysoką dostępność. Nie ma przestoju bazy danych, gdy wysoka dostępność jest włączona lub wyłączona w klastrze usługi Azure DocumentDB. Aby uzyskać szczegółowe instrukcje, zobacz Skalowanie klastra usługi DocumentDB Azure.

Zachowanie, gdy wszystkie strefy są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać podczas konfigurowania klastra usługi Azure DocumentDB dla wysokiej dostępności w regionie obsługującym strefy dostępności, a wszystkie strefy działają.

  • Operacja między strefami: Podstawowe fragmenty obsługują wszystkie żądania klientów. Zapasowe shardy w innej strefie dostępności nie obsługują żądań klientów, chyba że podstawowy shard ulegnie awarii.

  • Replikacja danych między strefami: Replikacja między fragmentami podstawowymi i rezerwowymi jest synchroniczna. Operacje zapisu są utrwalane zarówno na odłamkach podstawowych, jak i zapasowych, zanim usługa zwróci odpowiedź.

Zachowanie podczas awarii strefy

W tej sekcji opisano, czego można się spodziewać podczas konfigurowania klastra usługi Azure DocumentDB pod kątem wysokiej dostępności w regionie obsługującym strefy dostępności oraz gdy w jednej ze stref wystąpi awaria.

  • Wykrywanie i reagowanie: Microsoft monitoruje stan fragmentów oraz obsługuje wykrywanie i operacje przełączania awaryjnego za użytkownika. Jeśli podstawowy fragment stanie się niedostępny z powodu awarii strefy, usługa Azure DocumentDB automatycznie przełącza na zapasowy fragment, a następnie odtwarza nadmiarowość, tworząc nowy zapasowy fragment.

  • Powiadomienie: Firma Microsoft nie powiadamia cię automatycznie, gdy strefa nie działa. Można jednak użyć Azure Service Health aby zrozumieć ogólną kondycję usługi, w tym wszelkie błędy strefy, i skonfigurować alerty Service Health w celu powiadamiania o problemach.

  • Aktywne żądania: Żądania w locie, które nie zostały potwierdzone przed przejściem w tryb failover, mogą zakończyć się niepowodzeniem i muszą zostać ponowione przez klienta. Jeśli aplikacja obsługuje błędy przejściowe, te próby są zwykle wykonywane automatycznie.

  • Oczekiwana utrata danych: Azure usługa DocumentDB replikuje dane synchronicznie między fragmentami podstawowymi i rezerwowymi, więc nie oczekuje się utraty danych.

  • Oczekiwany przestój: Nie jest oczekiwany przestój w przypadku operacji odczytu. W przypadku operacji zapisu może wystąpić krótka przerwa podczas kończenia przełączenia awaryjnego. Jeśli aplikacja prawidłowo ponawia próby po wystąpieniu błędów przejściowych, zwykle objawia się to krótkim spowolnieniem.

  • Redystrybucja: Connection string nie zmienia się, więc klienci nadal korzystają z tego samego punktu końcowego. Usługa automatycznie przekierowuje ruch do promowanych fragmentów rezerwowych i ponownie kompiluje nowe fragmenty rezerwowe.

Odzyskiwanie strefy

Gdy strefa dostępności zostanie odzyskana, Azure DocumentDB automatycznie przywraca normalne operacje we wszystkich strefach używanych przez klaster.

Testowanie pod kątem niepowodzeń strefy

Platforma Azure DocumentDB zarządza routingiem ruchu, trybem failover i odzyskiwaniem strefy dla klastrów strefowo nadmiarowych. Nie musisz inicjować ani weryfikować procesów awarii strefy dostępności.

Odporność na awarie całego regionu

Każdy klaster usługi DocumentDB Azure jest wdrażany w jednym regionie Azure. Aby zapewnić odporność na awarie regionów, skonfiguruj replikację między regionami, dodając jeden klaster repliki w innym regionie.

Replikacja między regionami

Azure DocumentDB obsługuje replikację między regionami za pośrednictwem klastra repliki. Klaster repliki jest wyświetlany jako oddzielny klaster w grupie zasobów. Tego klastra replik można używać do odzyskiwania po awarii i skalowania operacji odczytu. Azure documentDB automatycznie i asynchronicznie replikuje zmiany danych z klastra podstawowego do klastra repliki.

Diagram replikacji asynchronicznej z klastra podstawowego Azure DocumentDB do klastra repliki do odczytu w innym regionie.

Jeśli region podstawowy ulegnie awarii, klaster repliki może zostać podwyższony, aby stał się klastrem odczytu i zapisu. Globalny parametr połączenia do odczytu i zapisu jest automatycznie aktualizowany tak, aby wskazywał promowany klaster.

Diagram awansowanej repliki usługi Azure DocumentDB obsługującej ruch po awarii regionu podstawowego.

W tej sekcji przedstawiono podsumowanie zagadnień dotyczących niezawodności replikacji między regionami. Aby uzyskać więcej informacji, zobacz Zarządzanie replikacją między regionami i w tym samym regionie w klastrze Azure DocumentDB oraz Najlepsze rozwiązania dotyczące replikacji między regionami i w tym samym regionie w usłudze Azure DocumentDB.

Przechodzenie na tryb awaryjny między regionami

usługa Azure DocumentDB obsługuje trzy tryby podwyższania poziomu:

  • Wymuszona promocja: Natychmiast promuje klaster repliki zapasowej tak, aby akceptował operacje zapisu, i przekierowuje przychodzący ruch zapisu za pośrednictwem globalnych parametrów połączenia do odczytu i zapisu. Ten tryb minimalizuje przestoje, ale może spowodować utratę danych, ponieważ utraci wszelkie niereplikowane zapisy.

  • Tryb failover zarządzany przez usługę: Klaster można skonfigurować do korzystania z trybu failover zarządzanego przez usługę. Microsoft monitoruje klaster podstawowy i automatycznie wyzwala wymuszone podwyższenie poziomu, jeśli klaster podstawowy jest w złej kondycji.

  • Promocyjna promocja: Zapobiega utracie danych, ale wymaga przestoju podczas replikacji niereplikowanych zapisów. Bezproblemowe podwyższenie poziomu wymaga, aby oba klastry działały w dobrej kondycji, więc nie można jej wykonać podczas awarii regionu.

Aby uzyskać więcej informacji, zobacz Tryby międzyregionalnego przełączania awaryjnego w usłudze Azure DocumentDB.

Requirements

  • Obsługa regionów: Replikację między regionami można używać we wszystkich regionach Azure obsługujących usługę Azure DocumentDB.

  • Warstwa obliczeniowa: Replikacja między regionami wymaga warstwy obliczeniowej M30 lub nowszej.

Zagadnienia do rozważenia

  • Dostęp sieciowy: Klastry replik nie dziedziczą ustawień sieciowych z klastra podstawowego. Skonfiguruj oddzielnie reguły zapory lub prywatne punkty końcowe w klastrze repliki i przetestuj łączność przed przełączeniem awaryjnym. Aby uzyskać więcej informacji, zobacz Ciągłe zapisy, operacje odczytu w replikach klastra i parametry połączenia.

  • Obsługa funkcji: Klastry replik nie obsługują odtwarzania do punktu w czasie (PITR) ani wysokiej dostępności w regionie.

    Jeśli w klastrze podstawowym włączono HA, odpowiadasz za ponowne włączenie HA w klastrze, który został promowany.

    Aby uzyskać więcej informacji, zobacz Limity i przydziały usługi Azure DocumentDB.

Cost

Replikacja między regionami zwiększa koszty zasobów obliczeniowych i zasobów pamięci masowej klastra repliki. Obowiązują również opłaty za transfer danych między regionami. Aby uzyskać szczegółowe informacje o cenach, zobacz Azure Cennik usługi DocumentDB i Cennik przepustowości.

Konfigurowanie obsługi wielu regionów

  • Utwórz klaster repliki: Aby włączyć replikację między regionami, utwórz klaster repliki z klastra podstawowego. Klaster repliki można utworzyć podczas tworzenia klastra podstawowego lub później. Aby uzyskać instrukcje, zobacz Zarządzanie replikacją między regionami i tym samym regionem w klastrze usługi Azure DocumentDB.

  • Konfigurowanie automatycznego trybu failover: Jeśli chcesz, aby Azure automatycznie podwyższyć poziom repliki podczas przestojów w regionie podstawowym, włącz tryb failover zarządzany przez usługę. Aby uzyskać więcej informacji, zobacz Włączanie trybu failover zarządzanego przez usługę.

    Note

    Microsoft zazwyczaj wyzwala tryb failover zarządzany przez usługę tylko w ekstremalnych zdarzeniach, takich jak awaria całego regionu lub duża liczba klientów, których dotyczy problem. Może wystąpić opóźnienie przed uruchomieniem przełączenia awaryjnego. Jeśli chcesz szybko przywrócić dostępność, zalecamy przeprowadzenie procesu przełączenia awaryjnego przy użyciu wymuszonej promocji zainicjowanej przez klienta.

Zachowanie, gdy wszystkie regiony są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać podczas konfigurowania klastra usługi Azure DocumentDB na potrzeby replikacji między regionami, a wszystkie regiony działają.

  • Operacja między regionami: Klaster podstawowy obsługuje cały ruch odczytu i zapisu. Klaster replik obsługuje ruch przeznaczony tylko do odczytu, którego można używać do skalowania operacji odczytu w poziomie lub do utrzymania ruchu odczytu lokalnie w określonym regionie. Globalny parametr połączenia do odczytu i zapisu zawsze wskazuje aktualny klaster do zapisu, więc klienci nie muszą śledzić, który region jest podstawowy.

  • Replikacja danych między regionami: Replikacja między klastrem podstawowym a klastrem repliki jest asynchroniczna. Zapisy są zatwierdzane w klastrze podstawowym i potwierdzane klientowi przed ich replikacją do klastra repliki. Takie podejście zapobiega opóźnieniu sieci między regionami, które ma wpływ na wydajność zapisu. Ponieważ replikacja jest asynchroniczna, niektóre opóźnienia replikacji są oczekiwane między klastrami podstawowymi i replikami, a wszystkie niereplikowane zapisy mogą zostać utracone podczas wymuszonego przejścia w tryb failover.

Zachowanie podczas awarii regionu

W tej sekcji opisano, czego można oczekiwać podczas konfigurowania klastra usługi Azure DocumentDB na potrzeby replikacji między regionami i awarii w regionie klastra podstawowego.

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

    • Jeśli włączono przełączenie awaryjne zarządzane przez usługę, usługa Azure DocumentDB wykrywa awarię i automatycznie wymusza promowanie klastra repliki.
    • Jeśli przełączanie awaryjne zarządzane przez usługę nie jest włączone, to Ty odpowiadasz za wykrycie awarii i uruchomienie wymuszonej promocji.

    Aby uzyskać więcej informacji, zobacz Tryby międzyregionalnego przełączania awaryjnego w usłudze Azure DocumentDB.

  • Powiadomienie: Firma Microsoft nie powiadamia cię automatycznie, gdy region nie działa. Można jednak użyć Azure Service Health, aby zrozumieć ogólną kondycję usługi, w tym awarie regionów, i skonfigurować alerty Service Health w celu powiadomienia o problemach.

  • Aktywne żądania: Wszelkie aktywne żądania do regionu podstawowego, które zakończyły się niepowodzeniem, mogą zakończyć się niepowodzeniem. Po zakończeniu pracy w trybie failover aplikacje powinny ponownie połączyć się z promowanym klastrem i ponowić próbę.

  • Oczekiwana utrata danych: Przejścia w tryb failover podczas awarii regionów są nieplanowane, dlatego niereplikowane zapisy mogą zostać utracone, ponieważ replikacja jest asynchroniczna.

  • Oczekiwany przestój: Ogólny przestój zależy od czasu wykrywania, trybu failover i zachowania ponownego łączenia klienta.

    W przypadku wymuszonej promocji zainicjowanej przez klienta łączny przestój obejmuje czas potrzebny na wykrycie awarii i zainicjowanie procesów odpowiedzi, a także czas ukończenia promocji.

    Po uruchomieniu promocji zwykle kończy się ona w ciągu kilku minut.

  • Ponowna dystrybucja: Globalny ciąg połączenia do odczytu i zapisu automatycznie wskazuje klaster awansowany po awansie. Aplikacje korzystające z parametrów połączenia specyficznych dla klastra mogą wymagać aktualizacji konfiguracji, aby kierować ruch do klastra w dobrej kondycji.

Odzyskiwanie regionów

Usługa Azure DocumentDB nie przełącza się automatycznie z powrotem do oryginalnego regionu po przywróceniu jego sprawności. Aby przywrócić operacje zapisu do pierwotnego regionu, wykonaj kolejną promocję po ponownym ustanowieniu preferowanej topologii. Użyj kontrolowanego promowania, aby uniknąć utraty danych podczas powrotu po awarii. Bezproblemowe przełączenie wymaga krótkiej przerwy w działaniu i można je przeprowadzić w wybranym przez siebie czasie, na przykład podczas okna serwisowego. Aby uzyskać więcej informacji, zobacz Wywoływanie łagodnego promowania.

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

Regularnie testuj proces odzyskiwania po awarii, promując klaster repliki w kontrolowanym środowisku.

  • Użyj wymuszonego awansowania, aby zasymulować zachowanie systemu podczas awarii. Ten test może spowodować utratę danych, dlatego rozważ uruchomienie tego testu w środowisku nieprodukcyjnym. Aby uzyskać więcej informacji, zobacz Wymuś promocję.

  • Użyj kontrolowanego przełączenia awaryjnego podczas planowanych ćwiczeń przełączenia, jeśli chcesz uniknąć utraty danych. Aby uzyskać więcej informacji, zobacz Wywoływanie łagodnego promowania.

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?.

Usługa Azure DocumentDB automatycznie tworzy ciągłe kopie zapasowe, które umożliwiają przywracanie do określonego momentu w czasie (PITR). Te automatyczne kopie zapasowe ułatwiają odzyskiwanie oryginalnych wersji po przypadkowym usunięciu lub zmodyfikowaniu danych. Azure usługa DocumentDB wykonuje kopie zapasowe bez wpływu na wydajność lub dostępność operacji bazy danych.

Azure DocumentDB przechowuje kopie zapasowe oddzielnie od danych źródłowych. W regionach obsługujących strefy dostępności usługa przechowuje migawki kopii zapasowych w trzech strefach dostępności. Azure usługa DocumentDB zarządza tymi kopiami zapasowymi i nie można ich wyeksportować. Usługa przechowuje kopie zapasowe przez 35 dni dla aktywnych klastrów, przez 7 dni dla aktywnych klastrów warstwy burstable (M10, M20, M25) oraz przez 7 dni dla usuniętych klastrów.

Możesz przywrócić kopię zapasową do nowego klastra. Po wykonaniu tej czynności należy wykonać zestaw zadań po zakończeniu przywracania.

Aby uzyskać więcej informacji, zobacz Przywracanie klastra w usłudze Azure DocumentDB.

Odporność usługi na prace konserwacyjne

Firma Microsoft regularnie stosuje aktualizacje usług i wykonuje inną konserwację. Platforma Azure automatycznie obsługuje te działania, zapewniając bezproblemową i przejrzystą konserwację. Podczas zdarzeń konserwacji nie przewiduje się przestoju, chyba że poinformowano Cię o zaplanowanej konserwacji Azure Service Health.

Planowane prace konserwacyjne mogą nadal powodować krótkotrwałe przejściowe awarie w operacjach klienta. Aplikacja powinna obsługiwać te zdarzenia, korzystając ze wskazówek dotyczących ponawiania prób w temacie Odporność na błędy przejściowe.

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.

W przypadku Azure DocumentDB umowy SLA dotyczące dostępności mają zastosowanie tylko wtedy, gdy klaster ma włączoną wysoką dostępność. Różne umowy SLA dotyczące dostępności mają zastosowanie do następujących konfiguracji:

  • Klastry o wysokiej dostępności rozciągające się na wiele regionów platformy Azure z użyciem replikacji między regionami.

  • Klastry z obsługą wysokiej dostępności w jednym regionie.

Treści powiązane

  • Last updated on