Omówienie i najlepsze rozwiązania dotyczące grup trybu failover (Usługa Azure SQL Database)

Dotyczy:Azure SQL Database

Funkcja grup przełączania awaryjnego umożliwia zarządzanie replikacją i przełączaniem awaryjnym niektórych lub wszystkich baz danych z serwera logicznego do serwera logicznego w innym regionie. Ten artykuł zawiera omówienie funkcji grupy przełączania awaryjnego oraz najlepsze praktyki i zalecenia dotyczące korzystania z niej z bazą danych Azure SQL Database.

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

Aby dowiedzieć się więcej o odzyskiwaniu po awarii usługi Azure SQL Database, obejrzyj ten film wideo:

Omówienie

Funkcja grup przełączeniowych umożliwia zarządzanie replikacją i przełączaniem awaryjnym baz danych do innego regionu Azure. Możesz wybrać wszystkie lub podzestaw baz danych użytkowników na serwerze logicznym, który ma być replikowany na inny serwer logiczny. Jest to deklaratywna abstrakcja na podstawie funkcji aktywnej replikacji geograficznej, zaprojektowana w celu uproszczenia wdrażania i zarządzania replikowanymi geograficznie bazami danych na dużą skalę.

Aby uzyskać informacje na temat celu punktu odzyskiwania danych (RPO) i czasu odzyskiwania (RTO) w trybie failover geograficznego, zobacz omówienie ciągłości działania.

Przekierowywanie punktu końcowego

Grupy przełączeniowe zapewniają punkty końcowe słuchacza do odczytu i zapisu oraz punkty tylko do odczytu, które pozostają niezmienione podczas geograficznego przełączania awaryjnego. Nie musisz zmieniać parametru połączenia dla aplikacji po awarii geograficznej, ponieważ połączenia automatycznie kierują się do bieżącego serwera głównego. Przełączenie geograficzne przełącza wszystkie bazy danych pomocniczych w grupie na rolę główną. Po zakończeniu przechodzenia w tryb failover geograficznie 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 zapewnić pełną ciągłość działania, dodanie regionalnej nadmiarowości bazy danych jest tylko częścią 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 podczas awarii usług, od których jest zależna.

Zasady trybu failover

Grupy przełączeń awaryjnych obsługują dwie zasady przełączania awaryjnego.

• Zarządzane przez klienta (zalecane) — klienci mogą przeprowadzić failover grupy, gdy zauważą nieoczekiwaną awarię, która wpływa na jedną lub więcej 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 wpływa na region podstawowy, firma Microsoft inicjuje przełączenie awaryjne wszystkich grup, których zasady przełączenia awaryjnego są skonfigurowane tak, aby były zarządzane 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 program PowerShell, interfejs wiersza polecenia platformy Azure lub interfejs API REST, wartość zasad trybu failover dla zarządzanego przez firmę 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:

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 zdarzenie klęski żywiołowej, zmiany konfiguracji, błędy oprogramowania lub awarie składników sprzętowych, a wiele baz danych w regionie jest dotkniętych.
• Okres karencji 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 awaryjne dla wszystkich grup przełączania awaryjnego w regionie, które mają politykę przełączania zarządzaną przez firmę Microsoft.

Ustaw politykę przełączania awaryjnego na zarządzaną 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ę.
• Jest dopuszczalne, aby wyzwalać wymuszone przełączenia awaryjne przez pewien czas po wygaśnięciu okresu karencji, ponieważ rzeczywisty czas takiego przełączenia może się znacznie różnić.
• Dopuszczalne jest, aby wszystkie bazy danych w grupie trybu awaryjnego zostały przełączone w tryb awaryjny, niezależnie od ich konfiguracji nadmiarowości strefowej lub stanu dostępności. Mimo że bazy danych skonfigurowane pod kątem nadmiarowości strefowej są odporne na awarie strefowe i mogą nie zostać dotknięte awarią, nadal będą one przełączane w tryb failover, jeśli są częścią grupy failover z zasadami przełączania zarządzanymi przez Microsoft.
• Dopuszczalne jest wymuszanie przełączeń awaryjnych baz danych w grupie przełączeń awaryjnych, niezależnie od zależności aplikacji od innych usług lub komponentów platformy Azure używanych przez aplikację, co może prowadzić do obniżenia wydajności lub niedostępności aplikacji.
• Akceptowalne jest poniesienie nieznanej ilości utraty danych, ponieważ dokładnego czasu wymuszonego failoveru nie można kontrolować, co ignoruje stan synchronizacji baz danych pomocniczych.
• Wszystkie podstawowe i pomocnicze bazy danych w grupie trybu failover oraz wszystkie relacje 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, zasady trybu failover zostaną ostatecznie zaktualizowane z opcji zarządzanej przez firmę Microsoft na opcję zarządzaną przez klienta w usłudze Azure SQL.

Po wyzwoleniu trybu failover przez firmę Microsoft, wpis o nazwie Failover Azure SQL failover group zostanie dodany do dziennika aktywności Azure Monitor. Wpis zawiera nazwę grupy awaryjnej w obszarze Zasób, a Zdarzenie zainicjowane przez wyświetla jeden łącznik (-), aby wskazać, że tryb awaryjny został zainicjowany przez firmę Microsoft. Te informacje można również znaleźć na stronie Dziennik aktywności nowego serwera podstawowego lub instancji w portalu Azure.

Terminologia i możliwości

• Grupa przełączania awaryjnego (FOG)

  Grupa awaryjnego przełączania to nazwana grupa baz danych zarządzanych przez pojedynczy serwer logiczny na platformie Azure, która może przejść w tryb awaryjnego przełączania jako całość do innego regionu Azure, jeśli wszystkie lub niektóre pierwotne bazy danych staną się niedostępne z powodu awarii w regionie pierwotnym.

  Ważne

  Nazwa grupy failover musi być unikatowa na poziomie globalnym w domenie .database.windows.net.

• Serwery

  Niektóre lub wszystkie bazy danych użytkowników na serwerze logicznym można umieścić w grupie przełączania awaryjnego. Ponadto serwer obsługuje wiele grup trybu failover na jednym serwerze.

• Podstawowe

  Serwer logiczny hostujący podstawowe bazy danych w grupie przełączania awaryjnego.

• Podrzędny

  Serwer logiczny hostujący zapasowe bazy danych w grupie przełączania awaryjnego. Pomocniczy nie może znajdować się w tym samym regionie Azure co podstawowy.

• Przełączenie awaryjne (failover, brak 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 system główny jest dostępny. Tryb failover jest używany w następujących scenariuszach:

  • Przeprowadź ćwiczenia odzyskiwania po awarii w środowisku produkcyjnym, gdy utrata danych nie jest akceptowalna.
  • Przenoszenie obciążenia do innego regionu
  • Zwróć obciążenie do regionu podstawowego po usunięciu awarii (powrót do stanu sprzed awarii)

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

  Wymuszone przełączenie awaryjne natychmiast przełącza serwer pomocniczy na rolę główną bez oczekiwania na propagację najnowszych zmian z głównego. Ta operacja może spowodować potencjalną utratę danych. Wymuszone przełączenie na failover jest używane 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 pomocniczym. 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 jednostki pomocniczej przy użyciu replikacji asynchronicznej, wymuszone przełączenie awaryjne grup za pomocą zasad przełączania awaryjnego zarządzanych przez firmę Microsoft może spowodować utratę danych. Zasady trybu failover można dostosować, aby odzwierciedlały tolerancję aplikacji na utratę danych. Konfigurując GracePeriodWithDataLossHours, można kontrolować, jak długo usługa Azure SQL czeka przed zainicjowaniem wymuszonego przełączenia, co może spowodować utratę danych.

• Dodawanie pojedynczych baz danych do grupy przełączania awaryjnego

  Możesz umieścić kilka pojedynczych baz danych na tym samym serwerze logicznym w tej samej grupie przełączania awaryjnego. Jeśli dodasz pojedynczą bazę danych do grupy trybu failover, automatycznie utworzy ona pomocniczą bazę danych przy użyciu tej samej wersji i rozmiaru obliczeniowego na serwerze pomocniczym określonym podczas tworzenia grupy trybu failover. Jeśli dodasz bazę danych, która ma już zapasową bazę danych na serwerze zapasowym, łącze replikacji geograficznej zostanie odziedziczone przez grupę. Po dodaniu bazy danych, która ma już pomocniczą bazę danych na serwerze, który nie jest częścią grupy trybu failover, na serwerze pomocniczym zostanie utworzona nowa pomocnicza baza danych.

  Ważne

  • Upewnij się, że pomocniczy serwer logiczny nie ma bazy danych o tej samej nazwie, chyba że jest to istniejąca pomocnicza baza danych.
  • Jeśli baza danych zawiera obiekty OLTP w pamięci, podstawowa baza danych i pomocnicza baza danych repliki geograficznej muszą mieć pasujące warstwy usług, ponieważ obiekty OLTP w pamięci znajdują się w pamięci. Niższa warstwa usługi w bazie danych repliki geograficznej może spowodować problemy z brakiem pamięci. W takim przypadku replika geograficzna 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 również spowodować niepowodzenie przełączeń awaryjnych. Aby tego uniknąć, upewnij się, że warstwa usługi pomocniczej bazy danych geograficznej jest zgodna z podstawową bazą danych. Uaktualnienia warstwy usług mogą być operacjami związanymi z wielkością danych i mogą zająć trochę czasu.

• Dodawanie baz danych w elastycznej puli do grupy przełączania awaryjnego

  Wszystkie lub kilka baz danych w elastycznej puli można umieścić w tej samej grupie trybu awaryjnego przełączania. Jeśli podstawowa baza danych znajduje się w elastycznej puli, pomocnicza zostanie automatycznie utworzona w elastycznej puli o tej samej nazwie (pula pomocnicza). Należy się upewnić, że serwer pomocniczy zawiera elastyczną pulę o tej samej nazwie i wystarczającą ilość wolnej pojemności do hostowania pomocniczych baz danych, które zostaną utworzone przez grupę trybu failover. Jeśli dodasz bazę danych do puli, która ma już pomocniczą bazę danych w puli pomocniczej, wówczas grupa dziedziczy to łącze replikacji geograficznej. Po dodaniu bazy danych, która ma już pomocniczą bazę danych na serwerze, który nie jest częścią grupy trybu failover, w puli pomocniczej zostanie utworzona nowa pomocnicza baza danych.

• Odbiornik do odczytu i zapisu grupy przełączania awaryjnego

  Rekord DNS CNAME wskazujący na bieżący serwer główny. Jest tworzony automatycznie, gdy tworzona jest grupa przełączenia awaryjnego i pozwala obciążeniu odczytu i zapisu niewidocznie ponownie połączyć się z serwerem podstawowym, gdy nastąpi zmiana serwera podstawowego po przełączeniu awaryjnym. Po utworzeniu grupy przełączania awaryjnego na serwerze rekord CNAME DNS dla adresu URL słuchacza jest tworzony jako <fog-name>.database.windows.net. Po przełączeniu awaryjnym rekord DNS jest automatycznie aktualizowany, aby przekierować nasłuchującego do nowego węzła głównego.

• Odbiornik grupy failover tylko do odczytu

  Rekord CNAME DNS wskazujący obecny serwer zapasowy. Jest tworzony automatycznie po utworzeniu grupy przełączenia awaryjnego i umożliwia obciążeniu SQL w trybie tylko do odczytu transparentne połączenie z drugorzędnym serwerem, gdy po przełączeniu zmienia się serwer drugorzędny. Po utworzeniu grupy trybu failover na serwerze rekord CNAME DNS dla adresu URL nasłuchiwacza jest tworzony jako <fog-name>.secondary.database.windows.net. Domyślnie przełączenie awaryjne odbiornika tylko do odczytu jest wyłączone, aby zapewnić, że wydajność elementu podstawowego nie jest zakłócona, gdy element pomocniczy jest w trybie offline. Jednak oznacza to również, że sesje tylko do odczytu nie będą mogły nawiązać połączenia, dopóki serwer pomocniczy nie zostanie przywrócony. 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 nasłuchującego tylko do odczytu, konfigurując właściwość AllowReadOnlyFailoverToPrimary. W takim przypadku ruch w trybie tylko do odczytu jest automatycznie przekierowywany do głównego, jeśli zapasowy nie jest dostępny.

  Uwaga

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

• Wiele grup przełączeniowych

  Można skonfigurować wiele grup przełączania awaryjnego dla tej samej pary serwerów, aby kontrolować zakres przełączania geograficznego. Każda grupa przełącza się niezależnie. Jeśli aplikacja typu tenant na bazę danych jest wdrażana w wielu regionach i korzysta z elastycznych pul, możesz użyć tej funkcji do łączenia głównych i pomocniczych baz danych w każdej puli. Dzięki temu można zmniejszyć wpływ awarii tylko na niektóre bazy danych dzierżaw.

Architektura grupy przełączania awaryjnego

Grupa trybu failover w usłudze Azure SQL Database może zawierać jedną lub wiele baz danych, zwykle używaną przez tę samą aplikację. Na serwerze podstawowym należy skonfigurować grupę trybu failover, która łączy ją z serwerem pomocniczym w innym regionie świadczenia usługi Azure. Grupa trybu failover może zawierać wszystkie lub niektóre bazy danych na serwerze podstawowym. Na poniższym diagramie przedstawiono typową konfigurację aplikacji w chmurze geograficznie nadmiarowej przy użyciu wielu baz danych w grupie trybu failover:

Podczas projektowania usługi z myślą o ciągłości działalności biznesowej postępuj zgodnie z ogólnymi wytycznymi i najlepszymi rozwiązaniami opisanymi w tym artykule. Podczas konfigurowania grupy przełączania awaryjnego upewnij się, że uwierzytelnianie i dostęp sieciowy dla systemu pomocniczego są skonfigurowane tak, aby działały prawidłowo po geo-przełączeniu awaryjnym, gdy środowisko pomocnicze stanie się nowym głównym. Aby uzyskać szczegółowe informacje, zobacz Konfigurowanie i zarządzanie zabezpieczeniami usługi Azure SQL Database na potrzeby geograficznego przywracania lub przełączenia awaryjnego. Aby uzyskać więcej informacji, zobacz Projektowanie globalnie dostępnych usług przy użyciu usługi Azure SQL Database i Przywracanie geograficzne dla usługi Azure SQL Database.

Korzystanie ze sparowanych regionów

Podczas tworzenia grupy trybu failover między serwerem podstawowym i pomocniczym należy użyć sparowanych regionów, ponieważ grupy trybu failover w sparowanych regionach mają lepszą wydajność w porównaniu z niesparowanymi regionami.

Zgodnie z bezpiecznymi praktykami wdrażania usługa Azure SQL Database zwykle nie aktualizuje sparowanych regionów 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 serwer podstawowy jest najpierw uaktualniany, a czasami jest uaktualniany drugi.

Jeśli masz skonfigurowane replikację geograficzną lub grupy failover dla baz danych, które nie są zgodne z parowaniem regionów platformy Azure, użyj różnych harmonogramów okien obsługi dla swoich podstawowych i pomocniczych baz danych. Możesz na przykład wybrać okno serwisowe w dni powszednie dla swojej pomocniczej bazy danych i okno serwisowe w weekendy dla swojej podstawowej bazy danych.

Wstępne sianie

Podczas dodawania baz danych lub elastycznych pul do grupy trybu failover istnieje początkowa faza rozmieszczania przed rozpoczęciem replikacji danych. Początkowa faza zasiewania jest najdłuższą i najdroższą operacją. Po zakończeniu początkowego zasiewu, dane są synchronizowane, a następnie replikowane są tylko późniejsze zmiany danych. Czas potrzebny na ukończenie początkowego rozmieszczania zależy od rozmiaru danych, liczby replikowanych baz danych, obciążenia podstawowych baz danych oraz szybkości połączenia sieciowego między podstawową i pomocniczą bazą danych. W normalnych okolicznościach możliwa szybkość rozpowszechniania wynosi do 500 GB na godzinę dla usługi SQL Database. Seedowanie jest wykonywane równolegle dla wszystkich baz danych.

Liczba baz danych w grupie failover

Liczba baz danych w grupie failover ma bezpośredni wpływ na czas trwania operacji failover i wymuszonego failover.

• Podczas przełączenia awaryjnego (znanego również jako planowane przełączenie awaryjne) upewniamy się, że wszystkie podstawowe bazy danych są w pełni zsynchronizowane z ich bazami pomocniczymi i osiągają stan gotowości. Aby uniknąć przeciążeń płaszczyzny sterowania, bazy danych są przygotowywane w partiach. Dlatego zdecydowanie zaleca się ograniczenie liczby baz danych w grupie awaryjnej.
• W przypadku wymuszonego przejścia w tryb failover faza przygotowania jest przyspieszona, ponieważ synchronizacja danych nie jest inicjowana. Aby uzyskać szybsze i przewidywalne czasy trwania pracy w trybie failover, warto zachować liczbę baz danych w grupie trybu failover do mniejszej liczby.

Użycie wielu grup awaryjnych do przełączania wielu baz danych

Jedną lub wiele grup rezerwowych można utworzyć między dwoma serwerami w różnych regionach (serwer główny i zapasowy). Każda grupa może zawierać jedną lub kilka baz danych, które są odzyskiwane jako jednostka, jeśli wszystkie lub niektóre podstawowe bazy danych staną się niedostępne z powodu awarii w regionie podstawowym. Utworzenie grupy trybu failover powoduje utworzenie pomocniczych baz danych geograficznych z tym samym celem usługi co podstawowa. Jeśli dodasz istniejącą relację replikacji geograficznej do grupy failover, upewnij się, że geosekundariusz jest skonfigurowany z tą samą warstwą usługi i rozmiarem obliczeniowym co podstawowy.

Użycie nasłuchiwacza odczyt-zapis (podstawowego)

W przypadku obciążeń do odczytu i zapisu należy użyć <fog-name>.database.windows.net jako nazwy serwera w parametrach połączenia. Połączenia są automatycznie kierowane do serwera podstawowego. Ta nazwa nie zmienia się po przejściu w tryb failover. Należy pamiętać, że tryb failover obejmuje aktualizowanie rekordu DNS, więc połączenia klienta są przekierowywane do nowego podstawowego tylko po odświeżeniu pamięci podręcznej DNS klienta. Czas wygaśnięcia (TTL) rekordu DNS podstawowego i pomocniczego odbiornika wynosi 30 sekund.

Używanie odbiornika tylko do odczytu (pomocniczego)

Jeśli masz logicznie izolowane obciążenia tylko do odczytu, które są odporne na opóźnienia danych, możesz uruchomić je na geograficznym wtórniku. W przypadku sesji tylko do odczytu użyj <fog-name>.secondary.database.windows.net jako nazwy serwera w parametrach połączenia. Połączenia są automatycznie kierowane do pomocniczego obszaru geograficznego. Zaleca się również wskazanie intencji odczytu w łańcuchu połączenia przy użyciu ApplicationIntent=ReadOnly.

W warstwach usług Premium, Krytyczne dla biznesu i Hiperskala, usługa SQL Database obsługuje używanie replik tylko do odczytu do odciążenia zapytań tylko do odczytu, przy użyciu parametru ApplicationIntent=ReadOnly w ciągu połączenia. Po skonfigurowaniu pomocniczego obszaru geograficznego można użyć tej funkcji, aby nawiązać połączenie z repliką tylko do odczytu w lokalizacji podstawowej lub w lokalizacji pomocniczej geograficznej:

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

Potencjalne obniżenie wydajności po przełączeniu na tryb awaryjny

Typowa aplikacja systemu Azure korzysta z wielu usług platformy Azure i obejmuje wiele składników. Przechodzenie grupy w tryb failover jest wyzwalane na podstawie stanu samej bazy danych Azure SQL Database. 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 przejściu podstawowych baz danych na region pomocniczy (DR) opóźnienie między składnikami zależnymi może wzrosnąć. Aby uniknąć wpływu większego opóźnienia na wydajność aplikacji, zapewnij nadmiarowość wszystkich składników aplikacji w regionie DR, postępuj zgodnie z tymi wytycznymi dotyczącymi zabezpieczeń sieci i zorganizuj przejście odpowiednich składników aplikacji w tryb failover obszaru geograficznego wraz z bazą danych.

Potencjalna utrata danych po wymuszonym przejściu w tryb failover

W przypadku awarii w regionie podstawowym ostatnie transakcje mogą nie zostać zreplikowane do pomocniczej lokalizacji geograficznej, a wymuszone przejście w tryb failover może spowodować utratę danych.

Powrót po awarii

Gdy grupy przełączania awaryjnego są konfigurowane z użyciem polityki przełączania awaryjnego zarządzanej przez Microsoft, wymuszone przełączenie awaryjne na geozapasowy serwer jest inicjowane w scenariuszu awarii zgodnie ze zdefiniowanym okresem karencji. Przywrócenie do starego serwera głównego musi być zainicjowane ręcznie.

Uprawnienia i ograniczenia

Przejrzyj przewodnik konfigurowania grupy trybu failover, aby uzyskać listę uprawnień i ograniczeń.

Zarządzanie grupami przełączania awaryjnego programowo

Grupami trybu failover można również zarządzać programowo przy użyciu środowiska Azure PowerShell, interfejsu wiersza polecenia (CLI) platformy Azure i interfejsu API REST. Aby uzyskać więcej informacji, zobacz Konfigurowanie grupy trybu failover dla usługi Azure SQL Database.

Włącz wysoką dostępność (nadmiarowość strefowa)

dostępność dzięki nadmiarowości zwiększa odporność, chroniąc przed awariami strefy dostępności w regionie.

Podczas tworzenia grupy trybu failover zawierającej co najmniej jedną bazę danych nie ma możliwości włączenia wysokiej dostępności dla pomocniczych baz danych, niezależnie od ustawień wysokiej dostępności podstawowych baz danych.

Nadmiarowość strefowa z bazami danych innych niż Hiperskala

Pomocnicze bazy danych utworzone za pośrednictwem grupy trybu failover nie będą miały domyślnie włączonej wysokiej dostępności. Po utworzeniu grupy failover włącz wysoką dostępność dla baz danych zawartych w grupie. To zachowanie ma zastosowanie również w przypadku utworzenia Active Geo-Replication, a następnie opcjonalnie dodać bazy danych do grupy przełączenia awaryjnego.

Redundancja strefowa w Hiperskali

Pomocnicze bazy danych utworzone w ramach grupy trybu failover będą dziedziczyć ustawienia wysokiej dostępności odpowiednich baz danych podstawowych. W związku z tym, jeśli podstawowa baza danych ma włączoną wysoką dostępność, pomocnicza baza danych będzie również mieć włączoną. Z drugiej strony, jeśli podstawowa baza danych nie ma włączonej wysokiej dostępności, pomocnicza baza danych nie będzie mogła jej włączyć.

Obsługa regionalna stref dostępności

W scenariuszu, w którym włączono wysoką dostępność w podstawowej bazie danych, a dodawana pomocnicza baza danych znajduje się w regionie, który nie obsługuje jeszcze stref dostępności, przepływ pracy zakończy się niepowodzeniem z komunikatem o błędzie z kodem 45122: "Tworzenie lub aktualizowanie operacji grupy trybu failover zostało zakończone pomyślnie; Nie można jednak dodać niektórych baz danych do grupy trybu failover ani usunąć ich z grupy trybu failover. Udostępnianie bazy danych lub puli redundantnej w strefach nie jest obsługiwane dla bieżącego żądania. Aby obejść ten problem, użyj aktywnej replikacji geograficznej, aby włączyć lub wyłączyć wysoką dostępność podczas tworzenia bazy danych pomocniczej. Następnie możesz opcjonalnie dodać te bazy danych do grupy przełączania awaryjnego.

Powiązana zawartość

• Aby uzyskać przykładowe skrypty, zobacz:
  • Konfigurowanie aktywnej replikacji geograficznej dla usługi Azure SQL Database przy użyciu programu PowerShell
  • Użyj programu PowerShell do konfigurowania aktywnej replikacji geograficznej dla bazy danych w puli w usłudze Azure SQL Database
  • Dodawanie usługi Azure SQL Database do grupy trybu failover przy użyciu programu PowerShell
• Aby zapoznać się z omówieniem i scenariuszami ciągłości działalności biznesowej, zobacz Omówienie ciągłości działania
• Aby dowiedzieć się więcej na temat automatycznych kopii zapasowych usługi Azure SQL Database, zobacz Automatyczne kopie zapasowe usługi SQL Database.
• Aby dowiedzieć się więcej na temat używania automatycznych kopii zapasowych na potrzeby odzyskiwania, zobacz Przywracanie bazy danych z kopii zapasowych zainicjowanych przez usługę.
• Aby dowiedzieć się więcej o wymaganiach dotyczących uwierzytelniania dla nowego serwera podstawowego i bazy danych, zobacz Zabezpieczenia usługi SQL Database po odzyskiwaniu po awarii.