Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Ten artykuł zawiera szczegółowe informacje na temat odporności regionalnej ze strefami dostępnościi odzyskiwaniem po awarii między regionami oraz ciągłością działania usługi Azure DocumentDB.
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 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ć obsługę stref dostępności, należy włączyć wysoką dostępność (HA).
HA pozwala uniknąć przestojów bazy danych dzięki utrzymywaniu kopii zapasowych każdego fragmentu w klastrze. Jeśli fragment ulegnie awarii, usługa Azure DocumentDB przełącza połączenia przychodzące z uszkodzonego 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 niż ich podstawowe fragmenty. Repliki wysokiej dostępności nie odbierają żądań od klientów, chyba że ich główna replika 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. Jeśli jednak region ulegnie awarii, wystąpi ryzyko rozległego przestoju i ewentualnej utraty danych.
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 (DR) odnosi się do praktyk używanych przez organizacje do odzyskiwania po wystąpieniu zdarzeń o dużym wpływie, takich jak klęski żywiołowe lub nieudane wdrożenia, które powodują przestoje i utratę danych. Niezależnie od przyczyny najlepszym rozwiązaniem dla awarii jest dobrze zdefiniowany i przetestowany plan odzyskiwania po awarii oraz projekt aplikacji, który aktywnie obsługuje odzyskiwanie po awarii. Przed rozpoczęciem tworzenia planu odzyskiwania po awarii zobacz Zalecenia dotyczące projektowania strategii odzyskiwania po awarii.
W przypadku DR firma Microsoft używa modelu wspólnej odpowiedzialności . W tym modelu firma Microsoft zapewnia dostępność podstawowej infrastruktury i usług platformy. Jednak wiele usług platformy Azure nie replikuje automatycznie danych ani nie wraca z regionu, w którym wystąpił błąd, aby przeprowadzić replikację krzyżową do innego włączonego regionu. W przypadku tych usług odpowiadasz za skonfigurowanie planu odzyskiwania danych po awarii, który jest dostosowany do Twojego obciążenia. Większość usług oferty platformy Azure jako usługa (PaaS) udostępnia funkcje i wskazówki wspierające DR. Możesz użyć funkcji specyficznych dla usługi, aby wspierać szybkie odzyskiwanie i ułatwić opracowanie planu odzyskiwania po awarii.
Usługa Azure DocumentDB 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 DocumentDB.
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.
Usługa Azure DocumentDB automatycznie wykonuje 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 pod kątem wysokiej dostępności
Wysoka dostępność (HA) powinna być włączona dla krytycznych klastrów usługi Azure DocumentDB z uruchomionymi 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 podstawowym a pomocniczym odłamkiem 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 z powodu awarii strefy lub regionu, zapasowy fragment zostanie automatycznie przekształcony w nowy podstawowy, a kolejny zapasowy fragment zostanie utworzony dla tego 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 przełączenie awaryjne z podstawowego do pomocniczego fragmentu, połączenia są bezproblemowo kierowane w tle do nowego podstawowego fragmentu.
Replikacja synchroniczna między fragmentami podstawowymi i pomocniczymi gwarantuje brak utraty danych w przypadku przejścia w tryb failover.
Dalsze kroki
- Przeczytaj więcej na temat zgodności funkcji z bazą danych MongoDB.
- Przejrzyj opcje migracji z bazy danych MongoDB do usługi Azure DocumentDB
- Rozpocznij od utworzenia konta.