Udostępnij za pośrednictwem

Omówienie i najlepsze praktyki dotyczące grup failover — Azure SQL Managed Instance

  • Artykuł

Dotyczy:Azure SQL Managed Instance

Funkcja grupy failover umożliwia zarządzanie replikacją i przełączaniem awaryjnym wszystkich baz danych użytkowników w wystąpieniu zarządzanym do innego regionu Azure. Ten artykuł zawiera omówienie funkcji grupy failover z najlepszymi praktykami i zaleceniami dotyczącymi korzystania z niej w usłudze Azure SQL Managed Instance.

Aby rozpocząć korzystanie z tej funkcji, zapoznaj się z artykułem Konfigurowanie grupy trybu failover dla usługi Azure SQL Managed Instance.

Omówienie

Funkcja grupy failover umożliwia zarządzanie replikacją i przełączaniem awaryjnym baz danych użytkowników w zarządzanym wystąpieniu do innego zarządzanego wystąpienia w innym regionie platformy Azure. Grupy failover zostały zaprojektowane w celu uproszczenia wdrażania i zarządzania bazami danych replikowanymi geograficznie na dużą skalę.

Aby uzyskać więcej informacji, zobacz Wysoka dostępność dla usługi Azure SQL Managed Instance. Aby uzyskać informacje na temat celu punktu odzyskiwania (RPO) i celu czasu odzyskiwania (RTO) dla geo-failover, zobacz omówienie ciągłości działania.

Przekierowywanie punktu końcowego

Grupy przełączania awaryjnego zapewniają punkty końcowe dla odbiorników odczytu i zapisu oraz tylko do odczytu, które pozostają niezmienione podczas awarii geograficznych. Nie musisz zmieniać łańcucha połączenia dla aplikacji po geograficznym failoverze, ponieważ połączenia są automatycznie kierowane do bieżącego podstawowego serwera. Tryb failover geograficznego przełącza wszystkie pomocnicze bazy danych w grupie na rolę podstawową. Po zakończeniu geo-failover, rekord DNS zostanie automatycznie zaktualizowany w celu przekierowania punktów końcowych do nowego regionu.

Odciążanie obciążeń tylko do odczytu

Aby zmniejszyć ruch do podstawowych baz danych, możesz również użyć pomocniczych baz danych w grupie trybu failover, aby odciążyć obciążenia tylko do odczytu. Użyj odbiornika tylko do odczytu, aby skierować ruch tylko do odczytu do pomocniczej bazy danych z możliwością odczytu.

Odzyskiwanie aplikacji

Aby osiągnąć pełną ciągłość działania biznesowego, dodanie regionalnej nadmiarowości bazy danych to tylko część rozwiązania. Odzyskiwanie kompleksowej aplikacji (usługi) po katastrofalnym niepowodzeniu wymaga odzyskania wszystkich składników, które stanowią usługę i wszelkie usługi zależne. Przykłady tych składników obejmują oprogramowanie klienckie (na przykład przeglądarkę z niestandardowym kodem JavaScript), frontony internetowe, magazyn i system DNS. Ważne jest, aby wszystkie składniki były odporne na te same awarie i stały się dostępne w ramach celu czasu odzyskiwania (RTO) aplikacji. W związku z tym należy zidentyfikować wszystkie usługi zależne i zrozumieć oferowane przez nich gwarancje i możliwości. Następnie należy podjąć odpowiednie kroki, aby upewnić się, że Twoja usługa działa poprawnie w przypadku awarii usług, od których jest zależna.

Polityka awaryjnego przełączania

Grupy failover obsługują dwie polityki failover.

  • Zarządzane przez klienta (zalecane) — klienci mogą wykonać failover grupy, gdy zauważą nieoczekiwaną awarię, która wpływa na co najmniej jedną bazę danych w grupie failover. W przypadku korzystania z narzędzi wiersza polecenia, takich jak program PowerShell, interfejs wiersza polecenia platformy Azure lub interfejs API REST, wartość zasad trybu failover dla zarządzanego przez klienta to manual.
  • Zarządzane przez firmę Microsoft — w przypadku awarii na szeroką skalę, która ma wpływ na region podstawowy, firma Microsoft inicjuje przejście w tryb failover wszystkich grup, na które mają wpływ zasady trybu failover skonfigurowane pod kątem zarządzania przez firmę Microsoft. Tryb failover zarządzany przez firmę Microsoft nie zostanie zainicjowany dla poszczególnych grup trybu failover ani podzbioru grup trybu failover w regionie. W przypadku korzystania z narzędzi wiersza polecenia, takich jak PowerShell, Azure CLI lub REST API, wartość zasad przełączenia awaryjnego dla opcji zarządzanej przez Microsoft to automatic.

Każda zasada trybu failover ma unikatowy zestaw przypadków użycia i odpowiednie oczekiwania dotyczące zakresu trybu failover i utraty danych, jak podsumowuje poniższa tabela:

Zasady trybu failover Zakres przełączania awaryjnego Przypadek użycia Potencjalna utrata danych
Zarządzane przez klienta
(Zalecane)		 Grupy zapasowe Co najmniej jedna baza danych w grupach przełączeniowych jest dotknięta awarią i staje się niedostępna. Możesz wybrać tryb failover. Tak
Zarządzany przez firmę Microsoft Wszystkie grupy failover w regionie Powszechna awaria w centrum danych, strefie dostępności lub regionie powoduje niedostępność baz danych, a zespół usługi Microsoft Azure SQL decyduje się na wymuszone przełączenie awaryjne.
Użyj tej opcji tylko wtedy, gdy chcesz delegować odpowiedzialność za odzyskiwanie po awarii firmie Microsoft, a aplikacja jest odporna na RTO (czas przestoju) przynajmniej przez jedną godzinę lub dłużej.		 Tak

Zarządzane przez klienta

W rzadkich przypadkach wbudowana dostępność lub wysoka dostępność nie wystarczy, aby zapobiec awarii, a bazy danych w grupie trybu failover mogą być niedostępne przez czas, który nie jest akceptowalny dla umowy dotyczącej poziomu usług (SLA) aplikacji korzystających z baz danych. Bazy danych mogą być niedostępne z powodu zlokalizowanego problemu mającego wpływ tylko na kilka baz danych lub na poziomie centrum danych, strefy dostępności lub regionu. W każdym z tych przypadków, aby przywrócić ciągłość działalności biznesowej, możesz zainicjować wymuszone przejście w tryb failover.

Ustawienie zasad trybu failover na zarządzane przez klienta jest zdecydowanie zalecane, ponieważ zapewnia kontrolę nad tym, kiedy należy zainicjować tryb failover i przywrócić ciągłość działania. Możesz zainicjować tryb failover, gdy zauważysz nieoczekiwaną awarię, która ma wpływ na co najmniej jedną bazę danych w grupie trybu failover.

Zarządzany przez firmę Microsoft

W przypadku zasad trybu failover zarządzanego przez firmę Microsoft odpowiedzialność za odzyskiwanie po awarii jest delegowana do usługi Azure SQL. Aby usługa Azure SQL mogła zainicjować wymuszone przejście w tryb failover, muszą zostać spełnione następujące warunki:

  • Awaria na poziomie centrum danych, strefy dostępności lub regionu spowodowana przez klęskę żywiołową, zmiany konfiguracji, błędy oprogramowania lub awarie komponentów sprzętowych wpływa na wiele baz danych w regionie.
  • Okres prolongaty wygasł. Ze względu na to, że weryfikowanie skali i łagodzenie awarii zależy od działań człowieka, okres prolongaty nie może być ustawiony poniżej jednej godziny.

Po spełnieniu tych warunków usługa Azure SQL inicjuje wymuszone przełączenia dla wszystkich grup przełączeniowych w regionie, które mają ustawioną politykę przełączenia na zarządzane przez Microsoft.

Ważne

Użyj zasad trybu failover zarządzanych przez klienta, aby przetestować i wdrożyć plan odzyskiwania po awarii. Nie należy polegać na zarządzanym przez firmę Microsoft trybie failover, który może być wykonywany tylko przez firmę Microsoft w ekstremalnych okolicznościach. Zarządzany przez firmę Microsoft tryb failover zostanie zainicjowany dla wszystkich grup failover w regionie, których polityka failover jest ustawiona na zarządzanie przez firmę Microsoft. Nie można tego zainicjować dla pojedynczej grupy failover. Jeśli potrzebujesz możliwości selektywnego przejścia w tryb failover do grupy trybu failover, użyj zasad trybu failover zarządzanych przez klienta.

Ustaw zasady trybu failover na zarządzane wyłącznie przez firmę Microsoft tylko wtedy, gdy:

  • Chcesz delegować odpowiedzialność za odzyskiwanie po awarii do usługi Azure SQL.
  • Aplikacja jest odporna na niedostępność bazy danych przez co najmniej jedną godzinę.
  • Dopuszczalne jest wyzwalanie wymuszonych przełączeń awaryjnych przez pewien czas po wygaśnięciu okresu prolongaty, ponieważ rzeczywisty czas takiego przełączenia może się znacznie różnić.
  • Dopuszczalne jest, aby wszystkie bazy danych w grupie trybu failover przejdą w tryb failover, niezależnie od ich konfiguracji nadmiarowości strefy lub stanu dostępności. Mimo że bazy danych skonfigurowane na potrzeby nadmiarowości strefowej są odporne na awarie strefowe i mogą nie być dotknięte awarią, nadal będą przełączane na tryb awaryjny, jeśli są częścią grupy przełączania awaryjnego z zasadami zarządzanymi przez firmę Microsoft.
  • Dopuszczalne jest wymuszanie przełączenia baz danych w grupie failover bez uwzględnienia zależności aplikacji od innych usług Azure lub komponentów używanych przez tę aplikację, co może spowodować spadek wydajności lub niedostępność aplikacji.
  • Akceptowalna jest utrata nieznanej ilości danych, ponieważ dokładny czas wymuszonego przełączenia awaryjnego (failover) nie może być kontrolowany i pomija stan synchronizacji pomocniczych baz danych.
  • Wszystkie podstawowe i pomocnicze bazy danych w grupie failover oraz wszystkie powiązania replikacji geograficznej mają tę samą warstwę usługi, warstwę obliczeniową (aprowizowaną lub bezserwerową) i rozmiar obliczeniowy (jednostki DTU lub rdzenie wirtualne). Jeśli cele poziomu usług (SLO) wszystkich baz danych nie są zgodne, zasada przełączania awaryjnego zostanie ostatecznie zaktualizowana z zarządzanej przez firmę Microsoft na zarządzane przez klienta przez usługę Azure SQL.

Po wyzwoleniu trybu failover przez firmę Microsoft, wpis o nazwie operacja grupy failover Azure SQL zostanie dodany do dziennika aktywności Azure Monitor. Wpis zawiera nazwę grupy przełączania awaryjnego w sekcji Zasób, a Zdarzenie zainicjowane przez wyświetla pojedynczy łącznik (-), by wskazać, że przełączenie awaryjne zostało zainicjowane przez firmę Microsoft. Te informacje można również znaleźć na stronie Dziennik aktywności nowego serwera podstawowego lub nowego wystąpienia w portalu Azure.

Terminologia i możliwości

  • Grupa awaryjna (FOG)

    Grupa trybu failover umożliwia wszystkim bazom danych użytkowników w wystąpieniu zarządzanym przełączanie w tryb failover jako jednostki do innego regionu świadczenia usługi Azure w przypadku niedostępności podstawowego wystąpienia zarządzanego z powodu awarii regionu podstawowego. Ponieważ grupy trybu failover dla usługi SQL Managed Instance zawierają wszystkie bazy danych użytkowników w wystąpieniu, na wystąpieniu można skonfigurować tylko jedną grupę trybu failover.

    Ważne

    Nazwa grupy przełączania awaryjnego musi być globalnie unikalna w domenie .database.windows.net.

  • Podstawowe

    Wystąpienie zarządzane hostujące podstawowe bazy danych w grupie trybu failover.

  • Podrzędny

    Wystąpienie zarządzane, które hostuje pomocnicze bazy danych w grupie trybu failover. Region pomocniczy nie może znajdować się w tym samym regionie świadczenia usługi Azure co region podstawowy.

    Ważne

    Jeśli baza danych zawiera obiekty OLTP w pamięci, to wystąpienie podstawowej i pomocniczej repliki geograficznej musi mieć pasujące warstwy usługi, ponieważ obiekty te są przechowywane w pamięci. Niższy poziom usługi w wystąpieniu repliki geograficznej może powodować problemy z brakiem pamięci. W takim przypadku replika pomocnicza może nie odzyskać bazy danych, powodując niedostępność pomocniczej bazy danych wraz z obiektami OLTP w pamięci na pomocniczym obszarze geograficznym. Z kolei może to spowodować niepowodzenie przejścia w tryb failover. Aby tego uniknąć, upewnij się, że poziom usługi instancji geodrugiej odpowiada poziomowi usługi bazy danych podstawowej. Uaktualnienia warstwy usług mogą wiązać się z operacjami związanymi z wielkością danych i mogą wymagać dłuższego czasu na ukończenie.

  • Tryb awaryjny (bez utraty danych)

    Tryb failover wykonuje pełną synchronizację danych między podstawowymi i pomocniczymi bazami danych, zanim pomocnicza przełączy się do roli podstawowej. Gwarantuje to brak utraty danych. Przełączenie awaryjne jest możliwe tylko wtedy, gdy serwer podstawowy jest dostępny. Tryb failover jest używany w następujących scenariuszach:

    • Przeprowadzanie ćwiczeń przywracania po awarii w środowisku produkcyjnym, gdy utrata danych nie jest akceptowalna.
    • Przenoszenie obciążenia do innego regionu
    • Zwróć obciążenie do regionu podstawowego po ograniczeniu awarii (powrót po awarii)

  • Wymuszone przejście w tryb failover (potencjalna utrata danych)

    Wymuszone przejście w tryb failover natychmiast przełącza serwer pomocniczy do roli serwera podstawowego bez oczekiwania na propagację ostatnich zmian z serwera podstawowego. Ta operacja może spowodować potencjalną utratę danych. Wymuszone przełączenie awaryjne jest stosowane jako metoda odzyskiwania podczas awarii, gdy serwer podstawowy nie jest dostępny. Gdy awaria zostanie złagodzona, stary serwer główny zostanie automatycznie ponownie połączony i stanie się nowym serwerem zapasowym. Można wykonać tryb failover w celu powrotu po awarii, zwracając repliki do ich oryginalnych ról podstawowych i pomocniczych.

  • Okres karencji z utratą danych

    Ponieważ dane są replikowane do pomocniczej przy użyciu replikacji asynchronicznej, wymuszone przejście w tryb failover grup przy użyciu zasad zarządzanych przez Microsoft może spowodować utratę danych. Zasady trybu failover można dostosować, aby odzwierciedlały tolerancję aplikacji na utratę danych. Konfigurując GracePeriodWithDataLossHours, możesz kontrolować, jak długo usługa Azure SQL czeka przed zainicjowaniem wymuszonego trybu awaryjnego przełączenia, co może prowadzić do utraty danych.

  • Strefa DNS

    Unikatowy identyfikator generowany automatycznie podczas tworzenia nowego wystąpienia zarządzanego SQL. Certyfikat wielodomenowy (SAN) jest dostarczany dla tego wystąpienia, aby uwierzytelniać połączenia klienta z dowolnym wystąpieniem w tej samej strefie DNS. Dwa wystąpienia zarządzane w tej samej grupie przełączania awaryjnego muszą współużytkować strefę DNS.

  • Odbiornik odczytu/zapisu grupy trybu failover

    Rekord CNAME DNS wskazujący na obecny główny. Jest tworzony automatycznie w momencie tworzenia grupy przełączeniowej i umożliwia obciążeniu związanym z odczytem i zapisem w sposób niewidoczny ponowne połączenie się z serwerem podstawowym, gdy serwer podstawowy zmienia się po przełączeniu awaryjnym. Po utworzeniu grupy przełączania awaryjnego w wystąpieniu zarządzanym SQL tworzony jest rekord CNAME systemu DNS dla adresu URL odbiornika jako <fog-name>.<zone_id>.database.windows.net.

  • Odbiornik tylko do odczytu grupy trybu failover

    Rekord CNAME DNS wskazujący na bieżący serwer sekundarny. Jest tworzony automatycznie po utworzeniu grupy failover i umożliwia obciążeniu SQL w trybie tylko do odczytu przezroczyste łączenie się z serwerem podrzędnym, gdy następuje zmiana serwera podrzędnego po przełączeniu awaryjnym. Po utworzeniu grupy zapasowej na zarządzanym wystąpieniu SQL, rekord CNAME DNS dla adresu URL odbiorcy jest tworzony jako <fog-name>.secondary.<zone_id>.database.windows.net. Domyślnie przełączanie awaryjne odbiornika tylko do odczytu jest wyłączone, ponieważ gwarantuje, że wydajność podstawowego nie ma wpływu, gdy element zapasowy jest w trybie offline. Jednak oznacza to również, że sesje tylko do odczytu nie będą mogły nawiązać połączenia, aż do momentu, kiedy druga baza danych zostanie odzyskana. Jeśli nie możesz tolerować przestojów dla sesji tylko do odczytu i możesz używać serwera podstawowego zarówno dla ruchu tylko do odczytu, jak i odczytu i zapisu, kosztem potencjalnego obniżenia wydajności serwera podstawowego, możesz włączyć tryb failover dla odbiornika tylko do odczytu, konfigurując właściwość AllowReadOnlyFailoverToPrimary. W takim przypadku ruch tylko do odczytu jest automatycznie przekierowywany do podstawowego, jeśli zapasowy nie jest dostępny.

    Uwaga

    Właściwość AllowReadOnlyFailoverToPrimary ma wpływ tylko wtedy, gdy polityka zarządzanego przez Microsoft przełączania awaryjnego jest włączona i wymuszone przełączenie awaryjne zostało wyzwolone. W takim przypadku, jeśli właściwość ma wartość True, nowy serwer podstawowy będzie obsługiwać zarówno sesje odczytu i zapisu, jak i sesje tylko do odczytu.

Architektura grupy failover

Należy skonfigurować grupę przełączania awaryjnego w wystąpieniu podstawowym i połączyć ją z wystąpieniem pomocniczym w innym regionie Azure. Wszystkie bazy danych użytkowników w wystąpieniu zostaną zreplikowane do wystąpienia pomocniczego. Systemowe bazy danych, takie jak master i msdb nie zostaną zreplikowane.

Na poniższym diagramie przedstawiono typową konfigurację aplikacji w chmurze o geograficznej redundancji przy użyciu grupy przełączania awaryjnego i zarządzanego wystąpienia.

diagram grupy trybu failover dla usługi Azure SQL Managed Instance.

Jeśli aplikacja używa usługi SQL Managed Instance jako warstwy danych, postępuj zgodnie z ogólnymi wytycznymi i najlepszymi rozwiązaniami opisanymi w tym artykule podczas projektowania pod kątem ciągłości działania.

Utwórz instancję geosekundarną

Aby zapewnić nie przerywaną łączność z podstawowym wystąpieniem zarządzanym SQL po przejściu w tryb failover, zarówno wystąpienia podstawowe, jak i pomocnicze muszą znajdować się w tej samej strefie DNS. Gwarantuje to, że ten sam certyfikat z wieloma domenami (SAN) może służyć do uwierzytelniania połączeń klientów z dowolnym z dwóch wystąpień w grupie przełączania awaryjnego. Gdy aplikacja jest gotowa do wdrożenia produkcyjnego, utwórz pomocnicze wystąpienie zarządzane SQL w innym regionie i upewnij się, że współudzieli strefę DNS z podstawowym wystąpieniem zarządzanym SQL. Można to zrobić, określając opcjonalny parametr podczas tworzenia. Jeśli używasz programu PowerShell lub interfejsu API REST, nazwa opcjonalnego parametru to DNSZonePartner. Nazwa odpowiedniego opcjonalnego pola w witrynie Azure Portal to Podstawowe wystąpienie zarządzane.

Ważne

Pierwsze zarządzane wystąpienie utworzone w podsieci określa strefę DNS dla wszystkich następnych wystąpień w tej samej podsieci. Oznacza to, że dwa wystąpienia z tej samej podsieci nie mogą należeć do różnych stref DNS.

Aby uzyskać więcej informacji na temat tworzenia pomocniczego wystąpienia zarządzanego SQL w tej samej strefie DNS co wystąpienie podstawowe, zobacz Konfigurowanie grupy trybu failover dla usługi Azure SQL Managed Instance.

Korzystanie ze sparowanych regionów

Aby poprawić wydajność, wdróż oba wystąpienia zarządzane w sparowanych regionach. Grupy trybu failover usługi SQL Managed Instance w sparowanych regionach mają lepszą wydajność niż w niesparowanych regionach.

Usługa Azure SQL Managed Instance jest zgodna z praktyką bezpiecznego wdrażania, w której sparowane regiony platformy Azure zwykle nie są wdrażane w tym samym czasie. Nie można jednak przewidzieć, który region zostanie uaktualniony jako pierwszy, więc kolejność wdrożenia nie jest gwarantowana. Czasami wystąpienie podstawowe jest najpierw uaktualniane, a czasami wystąpienie pomocnicze jest najpierw uaktualniane.

W sytuacjach, gdy usługa Azure SQL Managed Instance jest częścią grupy trybu failover, a wystąpienia w grupie nie należą do sparowanych regionów platformy Azure, wybierz różne harmonogramy okien obsługi dla podstawowej i pomocniczej bazy danych. Na przykład, wybierz czas na konserwację w dni robocze dla pomocniczej bazy danych geograficznej i czas na konserwację w weekend dla podstawowej bazy danych geograficznej.

Włączyć i zoptymalizować przepływ ruchu replikacji geograficznej między wystąpieniami

Łączność między podsieciami sieci wirtualnej hostującymi wystąpienia podstawowe i pomocnicze należy ustanowić i utrzymywać w celu zapewnienia nieprzerwanego przepływu ruchu związanego z replikacją geograficzną. Istnieje wiele sposobów zapewnienia łączności między wystąpieniami, które można wybrać na podstawie topologii sieci i zasad:

Globalna komunikacja równorzędna sieci wirtualnych (komunikacja równorzędna sieci wirtualnych) to zalecany sposób nawiązywania łączności między dwoma wystąpieniami w grupie trybu failover. Zapewnia ona prywatne połączenie o niskim opóźnieniu i wysokiej przepustowości między równorzędnymi sieciami wirtualnymi, wykorzystujące infrastrukturę szkieletową firmy Microsoft. W komunikacji między równorzędnymi sieciami wirtualnymi nie jest wymagany żaden publiczny Internet, bramy ani dodatkowe szyfrowanie.

Wstępne zasiewanie

Podczas ustanawiania grupy przełączania awaryjnego między wystąpieniami zarządzanymi istnieje początkowa faza zasiewania przed rozpoczęciem replikacji danych. Początkowa faza wysiewu jest najdłuższą i najdroższą częścią operacji. Po zakończeniu początkowego rozmieszczania dane są synchronizowane, a tylko kolejne zmiany danych są replikowane. Czas potrzebny na ukończenie początkowego rozmieszczania zależy od rozmiaru danych, liczby replikowanych baz danych, intensywności obciążenia w podstawowych bazach danych oraz szybkości połączenia między sieciami wirtualnymi hostujących wystąpienie podstawowe i pomocnicze, które w większości zależą od sposobu nawiązywania łączności. W normalnych okolicznościach i gdy łączność jest ustanawiana przy użyciu zalecanego globalnego peeringu sieci wirtualnych, szybkość przesyłania wynosi do 360 GB na godzinę dla usługi SQL Managed Instance. Seedowanie jest wykonywane równolegle dla partii baz danych użytkowników — niekoniecznie dla wszystkich baz danych jednocześnie. W przypadku wielu baz danych hostowanych w wystąpieniu może być potrzebnych wiele partii.

Jeśli szybkość połączenia między dwoma wystąpieniami jest niższa niż to, co jest konieczne, czas inicjowania prawdopodobnie zostanie zauważalnie wydłużony. Możesz użyć podanej szybkości rozmieszczania, liczby baz danych, całkowitego rozmiaru danych i szybkości łącza, aby oszacować, jak długo początkowa faza rozmieszczania będzie trwać przed rozpoczęciem replikacji danych. Na przykład w przypadku pojedynczej bazy danych o pojemności 100 GB początkowa faza inicjowania zajęłaby około 1,2 godziny, jeśli link może wypchnąć 84 GB na godzinę, a jeśli nie ma żadnych innych baz danych, które są rozmieszczane. Jeśli link może przenieść tylko 10 GB na godzinę, rozmieszczanie bazy danych o pojemności 100 GB może potrwać około 10 godzin. Jeśli istnieje wiele baz danych do replikacji, rozmieszczanie zostanie wykonane równolegle, a w połączeniu z powolną szybkością połączenia początkowa faza rozmieszczania może trwać znacznie dłużej, zwłaszcza jeśli równoległe rozmieszczanie danych ze wszystkich baz danych przekracza dostępną przepustowość łącza.

Ważne

W przypadku wyjątkowo wolnego lub zajętego łącza, co powoduje, że początkowa faza seeding może zająć kilka dni, tworzenie grupy trybu awaryjnego może przekroczyć limit czasu. Proces tworzenia zostanie automatycznie anulowany po upływie 6 dni.

Zarządzanie failoverem geograficznym do geograficznego wystąpienia pomocniczego

Grupa trybu failover zarządza przełączaniem geograficznym wszystkich baz danych na podstawowym zarządzanym wystąpieniu. Po utworzeniu grupy każda baza danych w wystąpieniu zostanie automatycznie geo-replikowana do wystąpienia pomocniczego. Nie można użyć grup trybu failover do zainicjowania częściowego trybu failover podzestawu baz danych.

Ważne

Jeśli baza danych zostanie porzucona w podstawowym wystąpieniu zarządzanym, zostanie również automatycznie porzucona w pomocniczym wystąpieniu zarządzanym geograficznie.

Korzystanie z nasłuchu odczytu i zapisu (podstawowe MI)

W przypadku obciążeń odczytu i zapisu użyj <fog-name>.zone_id.database.windows.net jako nazwy serwera. Połączenia są automatycznie kierowane do serwera podstawowego. Ta nazwa nie zmienia się po awaryjnym przełączeniu. Przejście na geograficzny tryb failover obejmuje aktualizację rekordu DNS, więc nowe połączenia klienckie są kierowane do nowego serwera podstawowego tylko po odświeżeniu pamięci podręcznej DNS klienta. Ponieważ instancja pomocnicza współdzieli strefę DNS z serwerem podstawowym, aplikacja kliencka będzie mogła ponownie się do niej połączyć przy użyciu tego samego certyfikatu SAN po stronie serwera. Istniejące połączenia klientów muszą zostać zakończone i ponownie utworzone w celu przekierowania do nowego serwera głównego. Nasłuchiwacz odczytu i zapisu oraz nasłuchiwacz tylko do odczytu nie można osiągnąć przez publiczny punkt końcowy dla zarządzanego wystąpienia.

Używanie odbiornika tylko do odczytu (pomocnicze wystąpienie zarządzane)

Jeśli masz logicznie izolowane obciążenia tylko do odczytu, które są odporne na opóźnienia danych, możesz uruchomić je w pomocniczej lokalizacji geograficznej. Aby połączyć się bezpośrednio z geosekundarnym, użyj <fog-name>.secondary.<zone_id>.database.windows.net jako nazwy serwera.

W warstwie Krytyczna dla biznesu usługa SQL Managed Instance obsługuje używanie replik tylko do odczytu do odciążania obciążeń zapytań tylko do odczytu, używając parametru ApplicationIntent=ReadOnly w ciągu połączenia. Po skonfigurowaniu pomocniczej replikacji geograficznej można użyć tej funkcji, aby nawiązać połączenie z repliką tylko do odczytu w lokalizacji podstawowej lub w lokalizacji replikowanej geograficznie:

  • Aby nawiązać połączenie z repliką przeznaczoną tylko do odczytu w lokalizacji podstawowej, użyj ApplicationIntent=ReadOnly i <fog-name>.<zone_id>.database.windows.net.
  • Aby nawiązać połączenie z repliką tylko do odczytu w lokalizacji pomocniczej, użyj polecenia ApplicationIntent=ReadOnly i <fog-name>.secondary.<zone_id>.database.windows.net.

Odbiornik do odczytu i zapisu oraz odbiornik tylko do odczytu nie są dostępne za pośrednictwem publicznego punktu końcowego dla zarządzanego wystąpienia.

Potencjalne obniżenie wydajności po przełączeniu awaryjnym

Typowa aplikacja systemu Azure korzysta z wielu usług platformy Azure i obejmuje wiele składników. Geograficzny failover grupy jest wyzwalany na podstawie stanu składników usługi Azure SQL. Niedostępność aplikacji może nie mieć wpływu na inne usługi platformy Azure w regionie podstawowym, a ich składniki mogą nadal być dostępne w tym regionie. Po przełączeniu podstawowych baz danych do regionu pomocniczego opóźnienie między składnikami zależnych może wzrosnąć. Upewnij się, że wszystkie składniki aplikacji w regionie pomocniczym są nadmiarowe, a podczas awarii przełączają się one razem z bazą danych, aby wydajność aplikacji nie była narażona na większe opóźnienia między regionami.

Potencjalna utrata danych po wymuszonym przejściu w tryb failover

W przypadku wystąpienia awarii w regionie podstawowym, ostatnie transakcje mogą nie zostać zreplikowane do pomocniczej lokalizacji geograficznej, co może prowadzić do utraty danych w przypadku wymuszonego przełączenia awaryjnego.

Aktualizacja DNS

Aktualizacja DNS odbiornika odczytu i zapisu zostanie wykonana natychmiast po zainicjowaniu trybu failover. Ta operacja nie spowoduje utraty danych. Jednak proces przełączania ról bazy danych może potrwać do 5 minut w normalnych warunkach. Dopóki nie zostanie ukończone, niektóre bazy danych w nowym głównym wystąpieniu będą wciąż dostępne tylko do odczytu. Jeśli tryb failover jest inicjowany przy użyciu programu PowerShell, operacja przełączania roli repliki podstawowej jest synchroniczna. Jeśli zainicjowano ją przy użyciu witryny Azure Portal, interfejs użytkownika wskazuje stan ukończenia. Jeśli jest inicjowany przy użyciu interfejsu API REST, użyj standardowego mechanizmu sondowania usługi Azure Resource Manager, aby monitorować ukończenie.

Ważne

Użyj ręcznego planowanego przejścia w tryb failover, aby przenieść element podstawowy z powrotem do oryginalnej lokalizacji po awarii, która spowodowała ograniczenie geograficznego trybu failover.

Oszczędzaj koszty dzięki bezpłatnej licencji na replikę odzyskiwania danych po awarii.

Możesz zaoszczędzić na kosztach licencji programu SQL Server, konfigurując pomocnicze wystąpienie zarządzane do użycia tylko na potrzeby odzyskiwania po awarii. Aby to skonfigurować, zobacz Konfigurowanie repliki rezerwowej bez licencji dla usługi Azure SQL Managed Instance.

Jeśli wystąpienie pomocnicze nie jest używane w przypadku obciążeń do odczytu, firma Microsoft zapewnia bezpłatną liczbę vCoreów odpowiadającą wystąpieniu podstawowemu. Nadal są naliczane opłaty za przetwarzanie i przechowywanie używane przez instancję pomocniczą. Grupy trybu failover obsługują tylko jedną replikę — replika musi być repliką do odczytu lub wyznaczoną jako replika wyłącznie do awaryjnego przywracania.

Włączanie scenariuszy zależnych od obiektów z systemowych baz danych

Systemowe bazy danych nie są replikowane do wystąpienia pomocniczego w grupie przełączenia awaryjnego. Aby włączyć scenariusze zależne od obiektów z systemowych baz danych, pamiętaj, aby utworzyć takie same obiekty w wystąpieniu pomocniczym i zachować ich synchronizację z wystąpieniem podstawowym.

Jeśli na przykład planujesz używać tych samych identyfikatorów logowania w wystąpieniu pomocniczym, pamiętaj, aby utworzyć je przy użyciu identycznego identyfikatora SID.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

Aby dowiedzieć się więcej, zobacz temat Replication of logins and agent jobs (Replikacja identyfikatorów logowania i zadań agenta).

Synchronizowanie właściwości instancji i instancji zasad przechowywania

Wystąpienia w grupie trybu failover pozostają oddzielnymi zasobami platformy Azure, a żadne zmiany konfiguracji wystąpienia podstawowego nie zostaną automatycznie zreplikowane do wystąpienia pomocniczego. Upewnij się, że wszystkie istotne zmiany są wykonywane zarówno na instancji podstawowej, jak i pomocniczej. Jeśli na przykład zmienisz nadmiarowość magazynu kopii zapasowych lub zasady długoterminowego przechowywania kopii zapasowych w wystąpieniu podstawowym, pamiętaj o zmianie go również w wystąpieniu pomocniczym.

Skalowanie wystąpień

Możesz skalować w górę lub skalować w dół wystąpienie podstawowe i pomocnicze do innego rozmiaru obliczeniowego w ramach tej samej warstwy usługi lub do innej warstwy usługi. Podczas skalowania w górę w tej samej warstwie usługi zalecamy najpierw skalowanie w górę pomocniczego obszaru geograficznego, a następnie skalowanie w górę podstawowego. Podczas skalowania w dół w ramach tej samej warstwy usługi należy odwrócić kolejność: najpierw przeskaluj w dół podstawową, a następnie pomocniczą. Podczas zmiany instancji na inną warstwę usługi to zalecenie jest egzekwowane. Sekwencja operacji jest wymuszana podczas skalowania poziomu usługi oraz rdzeni wirtualnych, a także przestrzeni przechowywania.

Ta sekwencja jest zalecana specjalnie w celu uniknięcia problemu, w którym pomocnicza replika geograficzna o niższym poziomie SKU jest przeciążona i musi zostać ponownie skonfigurowana podczas procesu aktualizacji lub degradacji.

Ważne

  • W przypadku wystąpień wewnątrz grupy failover zmiana warstwy usługi na warstwę Ogólnego Przeznaczenia Następnej Generacji lub z niej nie jest obsługiwana. Najpierw należy usunąć grupę przełączeniową przed modyfikacją którejkolwiek repliki, a następnie ponownie utworzyć grupę przełączeniową po wprowadzeniu zmiany.
  • Istnieje znany problem, który może mieć wpływ na dostępność wystąpienia skalowanego przy użyciu skojarzonego odbiornika grupy trybu failover.

Zapobieganie utracie krytycznych danych

Ze względu na duże opóźnienie sieci rozległe replikacja geograficzna używa mechanizmu replikacji asynchronicznej. Replikacja asynchroniczna sprawia, że utrata danych jest nieunikniona w przypadku awarii podstawowej. Aby chronić krytyczne transakcje przed utratą danych, deweloper aplikacji może wywołać składowaną procedurę sp_wait_for_database_copy_sync natychmiast po zatwierdzeniu transakcji. Wywołanie sp_wait_for_database_copy_sync blokuje wątek wywołujący do czasu, aż ostatnia zatwierdzona transakcja zostanie przesłana i utrwalona w dzienniku transakcji bazy danych pomocniczej. Jednak nie czeka na ponowne odtworzenie przesyłanych transakcji (odtworzenie) na serwerze pomocniczym. sp_wait_for_database_copy_sync jest przypisane do określonego łącza replikacji geograficznej. Każdy użytkownik z prawami połączenia do podstawowej bazy danych może wywołać tę procedurę.

Aby zapobiec utracie danych podczas inicjowanego przez użytkownika, planowanego geograficznego przełączenia awaryjnego, replikacja automatycznie i tymczasowo przechodzi na replikację synchroniczną, a następnie wykonuje przełączenie awaryjne. Następnie replikacja powraca do trybu asynchronicznego po zakończeniu geograficznego failovera.

Uwaga

sp_wait_for_database_copy_sync zapobiega utracie danych po awarii geograficznej dla określonych transakcji, ale nie gwarantuje pełnej synchronizacji dla dostępu do odczytu. Opóźnienie spowodowane sp_wait_for_database_copy_sync wywołaniem procedury może być znaczące i zależy od rozmiaru dziennika transakcji, który nie został jeszcze przesłany z serwera podstawowego w momencie wywołania.

Status grupy przełączania awaryjnego

Grupa awaryjna zgłasza swój status i opisuje bieżący stan replikacji danych.

  • Rozmieszczanie — początkowe rozmieszczanie odbywa się po utworzeniu grupy przełączania awaryjnego, dopóki wszystkie bazy danych użytkowników nie zostaną zainicjowane w instancji zapasowej. Nie można zainicjować procesu przełączania awaryjnego, gdy grupa przełączania awaryjnego znajduje się w stanie inicjalizacji, ponieważ bazy danych użytkowników nie są jeszcze kopiowane do instancji pomocniczej.
  • Synchronizowanie — zwykły stan grupy failover. Oznacza to, że zmiany danych w wystąpieniu podstawowym są replikowane asynchronicznie do wystąpienia pomocniczego. Ten stan nie gwarantuje, że dane są w pełni synchronizowane w każdej chwili. Mogą występować zmiany danych na podstawowej instancji, które nadal muszą być zreplikowane na instancję pomocniczą, ze względu na asynchroniczny charakter procesu replikacji między wystąpieniami w grupie przełączania awaryjnego. Zarówno automatyczne, jak i ręczne przechodzenie w tryb failover można zainicjować, gdy grupa trybu failover znajduje się w stanie Synchronizowanie.
  • Proces przełączania awaryjnego w toku – ten status wskazuje, że trwa proces automatycznego lub ręcznego przełączania awaryjnego. Nie można zainicjować żadnych zmian ani dodatkowych przełączeń awaryjnych, gdy grupa trybu failover jest w tym stanie.

Powrót po awarii

Gdy grupy failover są konfigurowane przy użyciu zasad przełączania awaryjnego zarządzanego przez firmę Microsoft, wymuszone przełączenie na geograficzny serwer pomocniczy jest inicjowane w przypadku awarii zgodnie ze zdefiniowanym okresem karencji. Powrót po awarii do starego podstawowego elementu musi zostać zainicjowany ręcznie.

Współdziałanie funkcji

Kopie zapasowe

Pełna kopia zapasowa jest wykonywana w następujących scenariuszach:

  • Zanim rozpocznie się początkowe seeding podczas tworzenia grupy trybu failover.
  • Po awarii.

Pełna kopia zapasowa to rozmiar operacji danych, których nie można pominąć ani odroczyć, i może zająć trochę czasu. Czas potrzebny do ukończenia zależy od rozmiaru danych, liczby baz danych i intensywności obciążenia podstawowych baz danych. Pełna kopia zapasowa może znacznie opóźnić wstępne rozmieszczanie i może opóźnić lub zapobiec operacji przejścia w tryb failover na nowym wystąpieniu wkrótce po przejściu w tryb failover.

Usługa Odtwarzania Dzienników

Bazy danych migrowane do Azure SQL Managed Instance przy użyciu usługi odtwarzania dziennika (LRS) nie mogą być dodane do grupy przełączenia awaryjnego do momentu wykonania kroku przeniesienia. Baza danych zmigrowana z użyciem LRS jest w stanie przywracania do momentu przełączenia, a bazy danych w stanie przywracania nie mogą być dodawane do grupy przełączania awaryjnego. Próba utworzenia grupy failover z bazą danych w stanie przywracania opóźnia utworzenie grupy failover do momentu zakończenia przywracania bazy danych.

Replikacja transakcyjna

Korzystanie z replikacji transakcyjnej z wystąpieniami w grupie trybu failover jest możliwe. Jeśli jednak skonfigurujesz replikację przed dodaniem wystąpienia zarządzanego SQL do grupy przełączania awaryjnego, replikacja zostanie wstrzymana po rozpoczęciu tworzenia grupy przełączania awaryjnego, a monitor replikacji wyświetli status Replicated transactions are waiting for the next log backup or for mirroring partner to catch up. Proces replikacji zostanie wznowiony po pomyślnym utworzeniu grupy trybu failover.

Jeśli zarządzane wystąpienie SQL wydawcy lub dystrybutora znajduje się w grupie przełączania awaryjnego, administrator zarządzanego wystąpienia SQL musi wyczyścić wszystkie publikacje na starym serwerze podstawowym i ponownie skonfigurować je na nowym serwerze podstawowym po wystąpieniu przełączenia awaryjnego. Zapoznaj się z przewodnikiem replikacji transakcyjnej, aby zapoznać się z krokami działań, które są wymagane w tym scenariuszu.

Uprawnienia i ograniczenia

Przed skonfigurowaniem grupy trybu failover przejrzyj listę uprawnień i ograniczeń .

Programowe zarządzanie grupami failover

Grupami failover można również zarządzać programistycznie przy użyciu Azure PowerShell, Azure CLI i REST API. Przejrzyj konfigurowanie grupy przełączania awaryjnego, aby dowiedzieć się więcej.

Ćwiczenia z odzyskiwania po awarii

Zalecanym sposobem wykonania próbnego odzyskiwania po awarii jest użycie ręcznego planowanego trybu failover zgodnie z następującym samouczkiem: Testowanie trybu failover.

Wykonanie ćwiczenia przy użyciu wymuszonego przejścia w tryb failover nie jest zalecane, ponieważ ta operacja nie zapewnia barier zabezpieczających przed utratą danych. Niemniej jednak możliwe jest osiągnięcie bezstratnego, wymuszonego failover, zapewniając spełnienie następujących warunków przed uruchomieniem wymuszonego failover:

  • Obciążenie jest zatrzymywane w głównym zarządzanym wystąpieniu.
  • Wszystkie długotrwałe transakcje zostały ukończone.
  • Wszystkie połączenia klienta z podstawowym wystąpieniem zarządzanym zostały rozłączone.
  • Stan grupy trybu failover to "Synchronizowanie".

Upewnij się, że dwa wystąpienia zarządzane mają przełączone role i że stan grupy trybu failover został zmieniony z "Failover w toku" na "Synchronizowanie" przed opcjonalnym ustanowieniem połączeń z nowym podstawowym wystąpieniem zarządzanym oraz uruchomieniem obciążenia do odczytu i zapisu.

Aby wykonać bezstratny powrót po awarii danych do oryginalnych ról wystąpienia zarządzanego, zdecydowanie zaleca się użycie ręcznego planowanego trybu failover zamiast wymuszonego przejścia w tryb failover. Jeśli zastosowano wymuszony powrót po awarii:

  • Wykonaj te same kroki co w przypadku bezstratnego przełączenia awaryjnego danych.
  • Dłuższy czas wykonania odtworzenia po awarii jest spodziewany, jeśli wymuszone odtworzenie po awarii nastąpi wkrótce po ukończeniu przejścia w tryb awaryjny, ponieważ musi poczekać na zakończenie zaległych operacji automatycznego tworzenia kopii zapasowej na byłym podstawowym zarządzanym wystąpieniu.
  • Wszelkie zaległe automatyczne operacje tworzenia kopii zapasowych w wystąpieniu zarządzanym przechodzącym z roli podstawowej do pomocniczej będą mieć wpływ na dostępność bazy danych w tym wystąpieniu.
  • Użyj stanu grupy trybu awaryjnego, aby określić, czy oba wystąpienia pomyślnie zmieniły swoje role i są gotowe do akceptowania połączeń od klientów.

Powiązana zawartość