Udostępnij za pośrednictwem

Niezawodność w usłudze Azure Cosmos DB dla rdzeni wirtualnych bazy danych MongoDB

  • Artykuł

DOTYCZY: Rdzenie wirtualne bazy danych MongoDB

Ten artykuł zawiera szczegółowe informacje na temat odporności regionalnej ze strefami dostępności i odzyskiwaniem po awarii między regionami oraz ciągłością biznesową dla usługi Azure Cosmos DB dla rdzeni wirtualnych bazy danych MongoDB.

Aby zapoznać się z omówieniem niezawodności architektury na platformie Azure, zobacz Niezawodność platformy Azure.

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?

Aby uzyskać obsługę stref dostępności, należy włączyć wysoką dostępność (HA).

Wysoka dostępność pozwala uniknąć przestojów bazy danych dzięki utrzymywaniu replik rezerwowych każdego fragmentu w klastrze. Jeśli fragment ulegnie awarii, usługa Azure Cosmos DB dla bazy danych MongoDB przełącza połączenia przychodzące z nieudanego fragmentu do repliki rezerwowej.

Po włączeniu wysokiej dostępności w regionie obsługującym strefy dostępności fragmenty replik wysokiej dostępności są aprowizowane w innej strefie dostępności od ich podstawowych fragmentów. Repliki wysokiej dostępności nie odbierają żądań od klientów, chyba że ich podstawowy fragment zakończy się niepowodzeniem.

Jeśli wysoka dostępność jest wyłączona, każdy fragment ma własny magazyn lokalnie nadmiarowy (LRS) z trzema synchronicznymi replikami obsługiwanymi przez usługę Azure Storage. Jeśli wystąpi awaria pojedynczej repliki, usługa Azure Storage wykryje błąd i w sposób przezroczysty ponownie utworzy odpowiednie dane. Aby uzyskać informacje na temat trwałości magazynu LRS, zobacz Podsumowanie opcji nadmiarowości. Jednak w przypadku awarii regionu ryzyko dużego przestoju i ewentualnej utraty danych jest możliwe.

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

Aby włączyć strefy dostępności, należy włączyć wysoką dostępność podczas tworzenia klastra lub w sekcji Skalowanie istniejącego klastra w witrynie Azure Portal.

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.

Rdzeń wirtualny usługi Azure Cosmos DB dla bazy danych MongoDB nie zapewnia wbudowanego automatycznego trybu failover ani odzyskiwania po awarii. Planowanie wysokiej dostępności to krytyczny krok w miarę skalowania rozwiązania.

Odzyskiwanie po awarii w lokalizacji geograficznej z jednym regionem

Aby zmaksymalizować czas pracy, zaplanuj ciągłość działania i przygotuj się do odzyskiwania po awarii za pomocą usługi Azure Cosmos DB dla rdzeni wirtualnych bazy danych MongoDB.

Chociaż usługi platformy Azure zostały zaprojektowane w celu zmaksymalizowania czasu pracy, mogą wystąpić nieplanowane awarie usług. Plan odzyskiwania po awarii gwarantuje, że masz strategię obsługi awarii usług regionalnych.

Rdzenie wirtualne usługi Azure Cosmos DB dla bazy danych MongoDB automatycznie tworzą kopie zapasowe danych w regularnych odstępach czasu. Automatyczne kopie zapasowe są wykonywane bez wpływu na wydajność i dostępność operacji bazy danych. Wszystkie kopie zapasowe są wykonywane automatycznie w tle i przechowywane oddzielnie od danych źródłowych w usłudze magazynu. Te automatyczne kopie zapasowe są przydatne w scenariuszach, gdy przypadkowo usuniesz lub zmodyfikujesz zasoby, a później wymagane są oryginalne wersje.

Automatyczne kopie zapasowe są zachowywane w różnych interwałach na podstawie tego, czy klaster jest obecnie aktywny, czy ostatnio usunięty.

Okres przechowywania
Aktywne klastry 35 dni
Usunięte klastry 7 dni

Projektowanie na potrzeby wysokiej dostępności

Wysoka dostępność (HA) powinna być włączona dla krytycznych klastrów rdzeni wirtualnych usługi Azure Cosmos DB dla bazy danych MongoDB z obciążeniami produkcyjnymi. W klastrze z włączoną wysoką dostępnością każdy fragment służy jako podstawowy wraz z fragmentem rezerwowym na gorąco aprowizowanym w innej strefie dostępności. Replikacja między elementem podstawowym a pomocniczym fragmentem jest domyślnie synchroniczna. Wszelkie modyfikacje bazy danych są utrwalane zarówno na fragmentach podstawowych, jak i pomocniczych (rezerwowych) przed odebraniem odpowiedzi z bazy danych.

Usługa obsługuje kontrole kondycji i pulsy do każdego podstawowego i pomocniczego fragmentu klastra. Jeśli podstawowy fragment stanie się niedostępny ze względu na strefę lub awarię regionalną, pomocniczy fragment zostanie automatycznie podwyższony do nowego podstawowego, a kolejny pomocniczy fragment zostanie skompilowany dla nowego podstawowego. Ponadto jeśli pomocniczy fragment stanie się niedostępny, usługa automatycznie tworzy nowy pomocniczy fragment z pełną kopią danych z bazy podstawowej.

Jeśli usługa wyzwala przejście w tryb failover z podstawowego do pomocniczego fragmentu, połączenia są bezproblemowo kierowane pod osłonami do nowego podstawowego fragmentu.

Replikacja synchroniczna między fragmentami podstawowymi i pomocniczymi gwarantuje brak utraty danych w przypadku przejścia w tryb failover.

Następne kroki