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

  • Artykuł

Dotyczy:Azure SQL Database

Funkcja grup trybu failover umożliwia zarządzanie replikacją i trybem failover niektórych lub wszystkich baz danych na serwerze logicznym na serwerze logicznym w innym regionie. Ten artykuł zawiera omówienie funkcji grupy trybu failover z najlepszymi rozwiązaniami i zaleceniami dotyczącymi korzystania z niej w usłudze Azure SQL Database.

Aby rozpocząć korzystanie z tej funkcji, zapoznaj się z artykułem Konfigurowanie grupy trybu failover.

Uwaga

W tym artykule opisano grupy trybu failover dla usługi Azure SQL Database. W przypadku usługi Azure SQL Managed Instance zobacz Grupy trybu failover w usłudze Azure SQL Managed Instance.

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

Omówienie

Funkcja grup trybu failover umożliwia zarządzanie replikacją i trybem failover baz danych w innym regionie świadczenia usługi 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 i celu punktu odzyskiwania w trybie failover geograficznego, zobacz omówienie ciągłości działania.

Przekierowywanie punktu końcowego

Grupy trybu failover zapewniają punkty końcowe odbiornika tylko do odczytu i odczytu, które pozostają niezmienione podczas przechodzenia w tryb failover geograficznego. Nie musisz zmieniać parametry połączenia dla aplikacji po przejściu w tryb failover geograficznie, ponieważ połączenia są automatycznie kierowane do bieżącego podstawowego elementu. Tryb failover geograficznego przełącza wszystkie pomocnicze bazy danych w grupie na rolę podstawową. 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 funkcje usługi podczas pracy w trybie failover usług, od których zależy.

Zasady trybu failover

Grupy trybu failover obsługują dwie zasady trybu failover:

  • Zarządzane przez klienta (zalecane) — klienci mogą wykonać tryb failover grupy, gdy zauważą nieoczekiwaną awarię, która ma wpływ na co najmniej jedną bazę danych w grupie trybu 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 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:

Zasady trybu failover Zakres trybu failover Przypadek użycia Potencjalna utrata danych
Zarządzane przez klienta
(Zalecane)		 Grupy trybu failover Co najmniej jedna baza danych w grupach trybu failover ma wpływ na awarię i stanie się niedostępna. Możesz wybrać tryb failover. Tak
Zarządzany przez firmę Microsoft Wszystkie grupy trybu 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 wyzwolenie wymuszonego przejścia w tryb failover.
Użyj tej opcji tylko wtedy, gdy chcesz delegować odpowiedzialność za odzyskiwanie po awarii firmie Microsoft, a aplikacja jest odporna na cel czasu odzyskiwania (przestój) co najmniej jedną godzinę.		 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 zdarzenie klęski żywiołowej, zmiany konfiguracji, błędy oprogramowania lub awarie składników sprzętowych i wiele baz danych w regionie ma wpływ.
  • 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 w tryb failover dla wszystkich grup trybu failover w regionie, w którym ustawiono zasady trybu failover na zarządzane przez firmę Microsoft.

Ustaw zasady trybu failover na zarządzane 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ń w tryb failover przez pewien czas po wygaśnięciu okresu prolongaty, ponieważ rzeczywisty czas wymuszonego przejścia w tryb failover 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 strefy są odporne na awarie strefowe i mogą nie mieć wpływu na awarię, nadal będą one przenoszone w tryb failover, jeśli są częścią grupy trybu failover z zasadami trybu failover zarządzanymi przez firmę Microsoft.
  • Dopuszczalne jest wymuszanie pracy w trybie failover baz danych w grupie trybu failover bez uwzględnienia zależności aplikacji od innych usług lub składników platformy Azure używanych przez aplikację, co może spowodować obniżenie wydajności lub niedostępność aplikacji.
  • Akceptowalne jest poniesienie nieznanej ilości danych, ponieważ dokładny czas wymuszonego przejścia w tryb failover nie może być kontrolowany i ignoruje stan synchronizacji pomocniczych baz danych.
  • Wszystkie podstawowe i pomocnicze bazy danych w grupie trybu failover mają tę samą warstwę usługi, warstwę obliczeniową (aprowizowaną lub bezserwerową) i rozmiar obliczeniowy (jednostki DTU lub rdzenie wirtualne). Jeśli cel poziomu usług (SLO) wszystkich baz danych w grupie trybu failover nie jest zgodny, zasady trybu failover zostaną ostatecznie zaktualizowane z zarządzanej przez firmę Microsoft do klienta zarządzanego przez usługę Azure SQL.

Po wyzwoleniu trybu failover przez firmę Microsoft wpis nazwy operacji trybu failover usługi Azure SQL w trybie failover zostanie dodany do dziennika aktywności usługi Azure Monitor. Wpis zawiera nazwę grupy trybu failover w obszarze Zasób, a zdarzenie zainicjowane przez program wyświetla jeden łącznik (-), aby wskazać, że tryb failover został zainicjowany przez firmę Microsoft. Te informacje można również znaleźć na stronie Dziennik aktywności nowego serwera podstawowego lub wystąpienia w witrynie Azure Portal.

Terminologia i możliwości

  • Grupa trybu failover (FOG)

    Grupa trybu failover to nazwana grupa baz danych zarządzanych przez pojedynczy serwer logiczny na platformie Azure , który może przejść w tryb failover jako jednostkę do innego regionu świadczenia usługi Azure, jeśli wszystkie lub niektóre podstawowe bazy danych staną się niedostępne z powodu awarii w regionie podstawowym.

    Ważne

    Nazwa grupy trybu failover musi być unikatowa w skali globalnej w domenie .database.windows.net.

  • Serwery

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

  • Podstawowe

    Serwer logiczny hostujący podstawowe bazy danych w grupie trybu failover.

  • Podrzędny

    Serwer logiczny hostujący pomocnicze bazy danych w grupie trybu failover. Pomocnicza nie może znajdować się w tym samym regionie świadczenia usługi Azure co podstawowy.

  • Tryb 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. Tryb failover jest możliwy tylko wtedy, gdy podstawowy jest dostępny. Tryb failover jest używany w następujących scenariuszach:

    • Wykonywanie próbnego 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 ograniczeniu awarii (powrót po awarii)

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

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

  • Okres prolongaty z utratą danych

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

  • Dodawanie pojedynczych baz danych do grupy trybu failover

    Można umieścić kilka pojedynczych baz danych na tym samym serwerze logicznym w tej samej grupie trybu failover. 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ż pomocniczą bazę danych na serwerze pomocniczym, to łącze replikacji geograficznej jest dziedziczone 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 spowodować również niepowodzenie przełączeń w tryb failover. 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 o rozmiarze danych i mogą zająć trochę czasu.

  • Dodawanie baz danych w elastycznej puli do grupy trybu failover

    Wszystkie lub kilka baz danych w elastycznej puli można umieścić w tej samej grupie trybu failover. 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 w puli, która ma już pomocniczą bazę danych w puli pomocniczej, to łącze replikacji geograficznej jest dziedziczone przez grupę. 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 odczytu/zapisu grupy trybu failover

    Rekord CNAME dns wskazujący bieżący podstawowy. Jest on tworzony automatycznie po utworzeniu grupy trybu failover i umożliwia obciążenie odczytu i zapisu w sposób niewidoczny ponownie nawiąż połączenie z serwerem podstawowym, gdy podstawowe zmiany po przejściu w tryb failover. Po utworzeniu grupy trybu failover na serwerze rekord CNAME dns dla adresu URL odbiornika jest tworzony jako <fog-name>.database.windows.net. Po przejściu w tryb failover rekord DNS jest automatycznie aktualizowany w celu przekierowania odbiornika do nowego podstawowego.

  • Odbiornik tylko do odczytu grupy trybu failover

    Rekord CNAME dns wskazujący bieżący pomocniczy. Jest on tworzony automatycznie po utworzeniu grupy trybu failover i umożliwia obciążeniu SQL tylko do odczytu przezroczyste łączenie się z pomocniczym, gdy zmiany pomocnicze po przejściu w tryb failover. Po utworzeniu grupy trybu failover na serwerze rekord CNAME dns dla adresu URL odbiornika jest tworzony jako <fog-name>.secondary.database.windows.net. Domyślnie tryb failover odbiornika tylko do odczytu jest wyłączony, ponieważ gwarantuje, że wydajność podstawowego elementu podstawowego nie ma wpływu, gdy pomocnicza 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 pomocnicza nie zostanie odzyskana. Jeśli nie możesz tolerować przestojów dla sesji tylko do odczytu i może używać podstawowej zarówno dla ruchu tylko do odczytu, jak i odczytu i zapisu kosztem potencjalnego obniżenia wydajności podstawowego, możesz włączyć tryb failover dla odbiornika tylko do odczytu, konfigurując AllowReadOnlyFailoverToPrimary właściwość. W takim przypadku ruch tylko do odczytu jest automatycznie przekierowywany do lokalizacji podstawowej, jeśli pomocnicza nie jest dostępna.

    Uwaga

    Właściwość AllowReadOnlyFailoverToPrimary ma wpływ tylko wtedy, gdy zasady trybu failover zarządzanego przez firmę Microsoft są włączone i wymuszone przejście w tryb failover zostało wyzwolone. W takim przypadku, jeśli właściwość ma wartość True, nowy podstawowy będzie obsługiwać zarówno sesje odczytu i zapisu, jak i tylko do odczytu.

  • Wiele grup trybu failover

    Można skonfigurować wiele grup trybu failover dla tej samej pary serwerów, aby kontrolować zakres trybów geograficznych trybu failover. Każda grupa jest w trybie failover niezależnie. Jeśli aplikacja dzierżawy na bazę danych jest wdrażana w wielu regionach i korzysta z elastycznych pul, możesz użyć tej funkcji do łączenia podstawowych 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 trybu failover

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:

Diagram shows a typical configuration of a geo-redundant cloud application using multiple databases and a failover group.

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 trybu failover upewnij się, że uwierzytelnianie i dostęp sieciowy w pomocniczym systemie jest skonfigurowane tak, aby działało prawidłowo po przejściu w tryb failover geograficznie, gdy pomocnicze środowisko geograficzne stanie się nowym podstawowym elementem podstawowym. Aby uzyskać szczegółowe informacje, zobacz Zabezpieczenia usługi SQL Database po odzyskiwaniu po awarii. Aby uzyskać więcej informacji, zobacz Projektowanie rozwiązań w chmurze na potrzeby odzyskiwania po awarii.

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 grupy replikacji geograficznej lub trybu failover skonfigurowane dla baz danych, które nie są zgodne z parowaniem regionów platformy Azure, użyj różnych harmonogramów okien obsługi dla podstawowych i pomocniczych baz danych. Możesz na przykład wybrać okno obsługi dzień powszedni dla pomocniczej bazy danych i okno obsługi weekendowej podstawowej bazy danych.

Wstępne rozmieszczanie

Podczas dodawania baz danych lub elastycznych pul do grupy trybu failover istnieje początkowa faza rozmieszczania przed rozpoczęciem replikacji danych. Początkowa faza rozmieszczania jest najdłuższą i najdroższą operacją. Po zakończeniu początkowego rozmieszczania dane są synchronizowane, a następnie replikowane są tylko kolejne 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ść rozmieszczania wynosi do 500 GB za godzinę dla usługi SQL Database. Rozmieszczanie jest wykonywane równolegle dla wszystkich baz danych.

Używanie wielu grup trybu failover do przełączania wielu baz danych w tryb failover

Jedną lub wiele grup trybu failover można utworzyć między dwoma serwerami w różnych regionach (serwery podstawowe i pomocnicze). 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 trybu failover, upewnij się, że pomocniczy obszar geograficzny jest skonfigurowany z tą samą warstwą usługi i rozmiarem obliczeniowym co podstawowy.

Używanie odbiornika odczytu i zapisu (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łączenie iony są automatycznie kierowane do 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 w pomocniczej lokalizacji geograficznej. W przypadku sesji tylko do odczytu użyj <fog-name>.secondary.database.windows.net jako nazwy serwera w parametrach połączenia. Połączenie są automatycznie kierowane do pomocniczego obszaru geograficznego. Zaleca się również wskazanie intencji odczytu w parametry połączenia przy użyciu polecenia ApplicationIntent=ReadOnly.

W warstwach usług Premium, Krytyczne dla działania firmy i Hiperskala usługa SQL Database obsługuje używanie replik tylko do odczytu do odciążania obciążeń zapytań tylko do odczytu przy użyciu parametru ApplicationIntent=ReadOnly w parametry 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 przejściu w tryb failover

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 wymuszonego przejścia w tryb failover aplikacji w regionie podstawowym ostatnie transakcje mogą nie zostać zreplikowane do pomocniczej lokalizacji geograficznej i może dojść do utraty danych.

Ważne

Elastyczne pule z 800 lub mniejszą liczbą jednostek DTU lub 8 lub mniejszą liczbą rdzeni wirtualnych, a więcej niż 250 baz danych może napotkać problemy, w tym dłuższe planowane tryby failover geograficzne i obniżoną wydajność. Takie problemy mogą występować częściej w przypadku obciążeń intensywnie korzystających z zapisu, gdy repliki geograficzne są dość odległymi lokalizacjami geograficznymi lub gdy dla każdej bazy danych jest używanych wiele pomocniczych replik geograficznych. Objawem tych problemów jest wzrost opóźnienia replikacji geograficznej w czasie, co może prowadzić do bardziej rozbudowanej utraty danych podczas awarii. Tę zwłokę można monitorować przy użyciu sys.dm_geo_replication_link_status. W przypadku wystąpienia tych problemów środki zaradcze obejmują skalowanie w górę puli w celu zwiększenia liczby jednostek DTU lub rdzeni wirtualnych albo zmniejszenie liczby replikowanych geograficznie baz danych w puli.

Powrót po awarii

Gdy grupy trybu failover są konfigurowane przy użyciu zasad trybu failover zarządzanego przez firmę Microsoft, wymuszone przejście w tryb failover na serwer pomocniczy geograficznie jest inicjowane w scenariuszu awarii zgodnie ze zdefiniowanym okresem prolongaty. Powrót po awarii do starego podstawowego elementu musi zostać zainicjowany ręcznie.

Uprawnienia i ograniczenia

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

Programowe zarządzanie grupami trybu failover

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.

Powiązana zawartość