Udostępnij przez


Najlepsze rozwiązania dotyczące replikacji między regionami i tymi samymi regionami w usłudze Azure DocumentDB

W tym artykule omówiono odzyskiwanie po awarii między regionami dla usługi Azure DocumentDB. Obejmuje również możliwości odczytu klastrów replik w tych samych lub innych regionach świadczenia usługi Azure na potrzeby skalowalności operacji odczytu.

Funkcja replikacji umożliwia replikowanie danych z klastra do klastra tylko do odczytu w innym lub tym samym regionie świadczenia usługi Azure. Repliki są aktualizowane za pomocą technologii replikacji asynchronicznej. Możesz mieć jedną replikę klastra w innym regionie dla podstawowego klastra usługi Azure DocumentDB. W rzadkim przypadku awarii regionu można podwyższyć poziom repliki klastra w innym regionie, aby stać się nowym klastrem odczytu i zapisu na potrzeby ciągłej operacji bazy danych MongoDB. Aplikacje mogą nadal używać tych samych ciągów połączeń, gdy replika klastra w innym regionie zostanie promowana na nowy klaster podstawowy.

Repliki to nowe klastry zarządzane podobnie do zwykłych klastrów. Dla każdej repliki do odczytu są naliczane opłaty za moc obliczeniową wirtualnych rdzeni oraz za magazynowanie w GiB/miesiąc. Koszty zasobów obliczeniowych i magazynowania dla klastrów replik mają taką samą strukturę jak zwykłe klastry i ceny regionu świadczenia usługi Azure, w którym są tworzone.

Odzyskiwanie po awarii przy użyciu klastrów replik

Replikacja między regionami jest jednym z kilku ważnych filarów strategii ciągłości działania i odzyskiwania po awarii (BCDR) platformy Azure. Replikacja między regionami asynchronicznie replikuje te same aplikacje i dane w innych regionach Azure w celu ochrony na wypadek awarii. Nie wszystkie usługi platformy Azure automatycznie replikują dane lub automatycznie wracają z regionu, który zakończył się niepowodzeniem, aby przeprowadzić replikację krzyżową do innego regionu z włączoną obsługą. Azure DocumentDB umożliwia utworzenie repliki klastra w innym regionie, a dane zapisane na klastrze podstawowym są automatycznie replikowane do tej repliki. Powrót do repliki klastra w przypadku awarii w głównym regionie musi zostać zainicjowany ręcznie.

Po włączeniu replikacji między regionami w klastrze usługi Azure DocumentDB każdy fragment jest stale replikowany do innego regionu. Ta replikacja utrzymuje replikę danych w wybranym regionie. Taka replika jest gotowa do użycia w ramach planu odzyskiwania po awarii w rzadkim przypadku awarii regionu podstawowego. Replikacja jest asynchroniczna. Operacje zapisu na fragmencie klastra podstawowego nie czekają na ukończenie replikacji do fragmentu repliki przed potwierdzeniem pomyślnego zapisu. Replikacja asynchroniczna pomaga uniknąć zwiększonych opóźnień operacji zapisu w klastrze podstawowym.

Ciągłe zapisy, operacje odczytu na replikach klastra i ciągi połączeń

Globalne parametry połączenia odczytu i zapisu w usłudze Azure DocumentDB stale kierują zapisy do aktywnego klastra z włączoną obsługą zapisu. Po zainicjowaniu podwyższania poziomu klastra repliki klaster repliki w regionie B jest przełączany do trybu zapisu, podczas gdy oryginalny klaster podstawowy w regionie A przechodzi do trybu tylko do odczytu. Przed promocją globalny łańcuch połączenia do odczytu-zapisu jest skierowany do klastra podstawowego w Regionie A, a następnie jest aktualizowany, aby wskazywać na Region B, gdy ten przejmuje obowiązki związane z zapisem. W przypadku aplikacji korzystających z globalnego parametry połączenia odczytu i zapisu operacje zapisu są bezproblemowo kontynuowane w całym procesie podwyższania poziomu, utrzymując nieprzerwany przepływ danych.

Klastry replik są również dostępne do odczytów. Pomaga to odciążać intensywne operacje odczytu z klastra podstawowego lub dostarczać mniejsze opóźnienia dla operacji odczytu do klientów znajdujących się bliżej regionu replikacji. Po włączeniu replikacji między regionami aplikacje mogą używać własnego parametry połączenia klastra repliki do wykonywania odczytów z repliki klastra. Klaster podstawowy jest dostępny dla operacji odczytu i zapisu przy użyciu własnych parametry połączenia.

Zrzut ekranu przedstawiający parametry połączenia klastra w usłudze Azure DocumentDB, w tym globalne parametry połączenia odczytu i zapisu oraz parametry połączenia samodzielnego.

Gdy tworzysz replikę poprzez włączenie replikacji między regionami lub w tym samym regionie, nie dziedziczy ona ustawień sieciowych, takich jak reguły zapory klastra podstawowego. Te ustawienia należy skonfigurować niezależnie dla repliki. Replika dziedziczy konto administratora z klastra podstawowego. Konta użytkowników muszą być zarządzane w klastrze podstawowym. Możesz nawiązać połączenie z klastrem podstawowym i jego klastrem repliki przy użyciu tych samych kont użytkowników.

Promocja klastra repliki

Jeśli wystąpi awaria regionu, możesz przeprowadzić odzyskiwanie po awarii, promując replikę klastra w innym regionie, aby umożliwić zapisy. Podczas operacji promocji repliki wykonywane są następujące kroki:

  1. Operacje zapisu w repliki w regionie B są włączone oprócz operacji odczytu. Była replika staje się nowym klastrem odczytu i zapisu.
  2. Promowany klaster repliki w regionie B akceptuje zapisy przy użyciu ciągów połączenia i globalnego ciągu połączenia do zapisu i odczytu.
  3. Klaster w regionie A jest skonfigurowany jako tylko do odczytu i utrzymuje łańcuch połączenia.

Ważne

Ponieważ replikacja jest asynchroniczna, niektóre dane z klastra w regionie A mogą nie być replikowane do regionu B po podwyższeniu poziomu repliki klastra w regionie B. Jeśli tak, podwyższenie poziomu spowoduje, że dane niereplikowane nie będą obecne w obu klastrach.

Metody uwierzytelniania w klastrach replik

Metody uwierzytelniania są zarządzane niezależnie w klastrach podstawowych i replik. Użytkownicy i inne podmioty zabezpieczeń, takie jak tożsamości zarządzane, są zawsze zarządzane w klastrze podstawowym i synchronizowane z klastrem repliki.

Jeśli klaster podstawowy ma natywną metodę uwierzytelniania usługi DocumentDB wyłączoną w momencie utworzenia klastra repliki, włączenie natywnego uwierzytelniania usługi DocumentDB w repliki nie jest dozwolone. Aby włączyć natywne uwierzytelnianie usługi DocumentDB w takiej repliki, należy najpierw ją promować.