Udostępnij przez

Niezawodność w usłudze Azure SQL Database

Usługa Azure SQL Database to w pełni zarządzany aparat bazy danych typu platforma jako usługa (PaaS), który obsługuje większość funkcji zarządzania bazami danych, takich jak uaktualnianie, stosowanie poprawek, tworzenie kopii zapasowych i monitorowanie bez udziału użytkownika.

W przypadku korzystania z platformy Azure niezawodność jest wspólną odpowiedzialnością. Firma Microsoft oferuje szereg możliwości wspierania odporności systemów i odzyskiwania. Odpowiadasz za zrozumienie sposobu działania tych funkcji we wszystkich usługach, których używasz, i wybierania funkcji, które są potrzebne do osiągnięcia celów biznesowych oraz wymagań dotyczących dostępności.

W tym artykule opisano, jak usługa Azure SQL Database jest odporna na różne potencjalne awarie i problemy, w tym przejściowe błędy, awarie stref dostępności i awarie regionów. W tym artykule opisano również, jak można używać kopii zapasowych do odzyskiwania po innych typach problemów, sposobu obsługi konserwacji usług i wyróżnia niektóre kluczowe informacje o umowie dotyczącej poziomu usług (SLA) usługi Azure SQL Database.

Zalecenia dotyczące wdrażania produkcyjnego

Aby dowiedzieć się, jak wdrożyć usługę Azure SQL Database, aby obsługiwać wymagania dotyczące niezawodności rozwiązania i jak niezawodność wpływa na inne aspekty architektury, zobacz Najlepsze rozwiązania dotyczące architektury usługi Azure SQL Database w przewodniku Azure Well-Architected Framework.

Omówienie architektury niezawodności

Usługa SQL Database działa w najnowszym stabilnym aplecie bazy danych programu SQL Server systemu operacyjnego Windows, w tym wszystkich odpowiednich poprawek.

Usługa SQL Database osiąga nadmiarowość, przechowując domyślnie trzy kopie danych w jednym centrum danych w regionie podstawowym. Takie podejście chroni dane w przypadku wystąpienia zlokalizowanych awarii, takich jak awaria sieci na małą skalę lub awaria zasilania, a także podczas następujących zdarzeń:

  • Zainicjowane przez klienta operacje zarządzania, które powodują krótki przestój

  • Operacje konserwacji usługi

  • Problemy i awarie centrum danych, w których centrum danych ma następujące składniki:

    • Stojaki, na których działają maszyny zasilające usługę

    • Maszyny fizyczne, które hostują maszynę wirtualną uruchamiającą silnik bazy danych SQL.

  • Inne problemy z silnikiem bazy danych SQL

  • Inne nieplanowane awarie zlokalizowane

Usługa SQL Database używa usługi Azure Service Fabric do zarządzania replikacją bazy danych.

Redundancja jest implementowana na różne sposoby dla różnych poziomów usług w bazie danych SQL Database. Aby uzyskać więcej informacji, zobacz Dostępność poprzez nadmiarowość w bazie danych SQL.

Odporność na błędy przejściowe

Błędy przejściowe to krótkotrwałe, sporadyczne awarie w komponentach. Występują one często w środowisku rozproszonym, takich jak chmura, i są one normalną częścią operacji. Błędy przejściowe naprawiają się po krótkim czasie. Ważne jest, aby aplikacje mogły obsługiwać błędy przejściowe, zwykle ponawiając próby żądań, których dotyczy problem.

Wszystkie aplikacje hostowane w chmurze powinny postępować zgodnie ze wskazówkami dotyczącymi obsługi błędów przejściowych platformy Azure podczas komunikowania się z dowolnymi interfejsami API hostowanymi w chmurze, bazami danych i innymi składnikami. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące obsługi błędów przejściowych.

Usługa SQL Database automatycznie obsługuje krytyczne zadania obsługi, takie jak stosowanie poprawek, kopie zapasowe, system Windows i uaktualnienia aparatu usługi SQL Database. Automatycznie obsługuje również nieplanowane zdarzenia, takie jak awarie sprzętu, oprogramowania lub sieci bazowej. Usługa SQL Database została zaprojektowana tak, aby szybko odzyskiwać dane po krytycznych awariach, co gwarantuje, że dane są zawsze dostępne. Większość użytkowników nie zauważa, że uaktualnienia są wykonywane w sposób ciągły.

W przypadku stosowania poprawek lub przełączania bazy danych w tryb failover przestój nie jest zakłócany w przypadku zastosowania logiki ponawiania prób w aplikacji.

Odporność aplikacji można przetestować na błędy przejściowe, postępując zgodnie ze wskazówkami w artykule Testowanie odporności błędów aplikacji.

Odporność na błędy strefy dostępności

Strefy dostępności są fizycznie oddzielnymi grupami centrów danych w regionie świadczenia usługi Azure. Gdy jedna strefa ulegnie awarii, usługi mogą przejść w tryb failover do jednej z pozostałych stref.

Można utworzyć strefowo nadmiarową pojedynczą bazę danych lub elastyczną pulę. Nadmiarowość stref zapewnia odporność bazy danych na duży zestaw awarii, w tym katastrofalne awarie centrum danych bez żadnych zmian logiki aplikacji.

W przypadku warstwie usługi o ogólnym przeznaczeniu, redundancja strefowa gwarantuje, że zarówno bezstanowe składniki obliczeniowe, jak i stanowe składniki magazynowania danych w usłudze SQL Database są odporne na awarię stref dostępności.

W przypadku warstw usług Premium, Business Critical i Hyperscale, nadmiarowość strefowa umieszcza repliki bazy danych SQL w wielu strefach dostępności platformy Azure w regionie podstawowym. Aby wyeliminować pojedynczy punkt awarii (SPOF), pierścień sterowania jest również duplikowany w wielu strefach dostępności.

Aby wyświetlić informacje o obsłudze strefy dostępności dla innych warstw usług, należy wybrać odpowiednią warstwę usługi na początku tej strony.

Requirements

Poziomy usług Podstawowy i Standardowy nie obsługują redundancji strefowej.

Nadmiarowość strefowa jest dostępna w bazach danych w warstwach usług: Kluczowe dla biznesu, Ogólne przeznaczenie i Hiperskala modelu zakupów opartych na rdzeniach wirtualnych, oraz w modelu zakupów opartych na jednostkach DTU dostępna jest tylko warstwa usługi Premium.

W przypadku warstwy usługi o ogólnym przeznaczeniu:

W przypadku warstw usługi Premium i Krytyczne dla działania firmy:

Dla poziomu usługi Hiperskala:

Aby wyświetlić informacje o obsłudze strefy dostępności dla innych warstw usług, należy wybrać odpowiednią warstwę usługi na początku tej strony.

Rozważania

  • Opóźnienie: Bazy danych rozproszone strefowo mają repliki w oddzielnych centrach danych. Dodane opóźnienie sieci może zwiększyć czas zatwierdzania transakcji i potencjalnie wpływać na wydajność niektórych obciążeń przetwarzania transakcji online (OLTP). Większość aplikacji nie jest wrażliwa na to dodatkowe opóźnienie.

  • master baza danych: gdy baza danych z konfiguracją strefowo redundantną jest tworzona na serwerze logicznym, master skojarzona baza danych z serwerem jest również automatycznie strefowo redundantna. Aby uzyskać więcej informacji o sprawdzaniu, czy baza danych master jest redundantna w strefie, zobacz Dostępność strefowa bazy danych.

Aby wyświetlić informacje o obsłudze strefy dostępności dla innych warstw usług, należy wybrać odpowiednią warstwę usługi na początku tej strony.

Koszt

W przypadku warstwy usługi Ogólnego Przeznaczenia jest naliczana dodatkowa opłata za włączenie nadmiarowości strefowej dla usługi SQL Database. Aby uzyskać więcej informacji, zobacz Cennik — SQL Database.

Warstwy usługi Premium i Krytyczne dla działania firmy zapewniają wiele replik bazy danych. Po włączeniu nadmiarowości strefowej, repliki zostają rozdzielone między strefami dostępności. To oznacza, że nie ma dodatkowych kosztów związanych z włączeniem redundancji strefy w bazie danych SQL, gdy znajduje się ona w warstwie usługi Premium lub Business Critical.

Jeśli włączysz wiele replik bazy danych usługi warstwy Hiperskala, możesz włączyć redundancję strefy. Po włączeniu nadmiarowości strefowej, repliki zostają rozdzielone między strefami dostępności. pl-PL: Ta dystrybucja oznacza, że nie ma dodatkowych kosztów związanych z włączaniem redundancji strefy w bazie danych SQL, gdy znajduje się ona w warstwie usługi Hiperskala, przy założeniu posiadania wielu replik.

Aby wyświetlić informacje o obsłudze strefy dostępności dla innych warstw usług, należy wybrać odpowiednią warstwę usługi na początku tej strony.

Konfiguruj obsługę stref dostępności

W warstwach usługi Ogólnego Przeznaczenia, Premium i O krytycznym znaczeniu dla działalności biznesowej:

  • Nowe zasoby: Bazę danych można skonfigurować tak, aby była strefowo nadmiarowa podczas jej tworzenia. Aby uzyskać więcej informacji, zobacz Szybki start: tworzenie pojedynczej bazy danych — SQL Database.

  • Istniejące zasoby: Możesz ponownie skonfigurować istniejącą bazę danych, aby uzyskać strefową nadmiarowość. Aby uzyskać więcej informacji, zobacz temat Włączenie redundancji strefowej - SQL Database.

    Wszystkie operacje skalowania usługi SQL Database, w tym włączanie nadmiarowości strefowej, są operacjami online i wymagają minimalnego lub żadnego przestoju. Aby uzyskać więcej informacji, zobacz Dynamiczne skalowanie zasobów bazy danych przy minimalnych przestojach.

  • Wyłącz nadmiarowość strefy: Nadmiarowość strefy można wyłączyć. Ten proces jest operacją online podobną do zwykłego uaktualnienia celu warstwy usług. Na końcu procesu baza danych jest migrowana z pierścienia strefowo nadmiarowego do pierścienia jednostrefowego.

Dla poziomu usługi Hiperskala:

Aby wyświetlić informacje o obsłudze strefy dostępności dla innych warstw usług, należy wybrać odpowiednią warstwę usługi na początku tej strony.

Zachowanie, gdy wszystkie strefy są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać, gdy bazy danych są skonfigurowane dla nadmiarowości strefowej, a wszystkie strefy dostępności są w pełni operacyjne.

W przypadku warstwy usługi o ogólnym przeznaczeniu:

  • Routing ruchu między strefami: Żądania są kierowane do węzła z uruchomioną warstwą obliczeniową bazy danych SQL. Gdy włączona jest nadmiarowość strefy, ten węzeł może znajdować się w dowolnej strefie dostępności.

  • Replikacja danych między strefami: Pliki danych i dziennika są synchronicznie replikowane w strefach dostępności przy użyciu ZRS. Operacje zapisu nie są uznawane za ukończone, dopóki dane nie będą pomyślnie replikowane we wszystkich strefach dostępności. Ta synchroniczna replikacja zapewnia silną spójność i zero utraty danych podczas awarii strefy. Jednak może to spowodować nieco większe opóźnienie zapisu w porównaniu z magazynem lokalnie nadmiarowym (LRS).

W przypadku warstw usługi Premium i Krytyczne dla działania firmy:

  • Routing ruchu między strefami: Repliki są rozproszone w różnych strefach dostępności, a jedna z tych replik jest wyznaczona jako replika podstawowa . Żądania są kierowane do podstawowej repliki twojej bazy danych.

  • Replikacja danych między strefami: Replika podstawowa stale wypycha zmiany do replik pomocniczych sekwencyjnie, aby upewnić się, że dane są utrwalane na wystarczającej liczbie replik pomocniczych przed zatwierdzeniem każdej transakcji. Ten proces gwarantuje, że jeśli replika podstawowa lub replika pomocnicza z możliwością odczytu staną się niedostępne z jakiegokolwiek powodu, w pełni zsynchronizowana replika jest zawsze dostępna do pracy w trybie failover. Po włączeniu redundancji strefowej te repliki znajdują się w różnych strefach dostępności. Jednak proces może spowodować nieco większe opóźnienie zapisu ze względu na opóźnienie sieci w strefach przechodzenia.

Dla poziomu usługi Hiperskala:

  • Routing ruchu między strefami: Repliki bazy danych są dystrybuowane między strefami dostępności, a jedna z tych replik jest wyznaczona jako replika podstawowa . Żądania są kierowane do podstawowej repliki twojej bazy danych.

  • Replikacja danych między strefami: Podstawowa replika bazy danych wypycha zmiany za pośrednictwem usługi dziennika odpornego na awarie stref, która replikuje wszystkie te zmiany synchronicznie pomiędzy strefami dostępności. Serwery stron znajdują się w każdej strefie dostępności i przechowują stan bazy danych. Ten proces gwarantuje, że jeśli replika podstawowa lub replika pomocnicza z możliwością odczytu stanie się niedostępna z jakiegokolwiek powodu, w pełni zsynchronizowana replika jest zawsze dostępna do pracy w trybie failover. Jednak proces może spowodować nieco wyższe opóźnienie zapisu w porównaniu z opóźnieniem LRS.

Aby wyświetlić informacje o obsłudze strefy dostępności dla innych warstw usług, należy wybrać odpowiednią warstwę usługi na początku tej strony.

Zachowanie podczas awarii strefy

W tej sekcji opisano, czego można się spodziewać, gdy bazy danych są skonfigurowane pod kątem nadmiarowości w strefie i występuje przerwa w strefie dostępności.

  • Wykrywanie i reagowanie: Usługa SQL Database jest odpowiedzialna za wykrywanie awarii i reagowanie na nie w strefie dostępności. Nie musisz nic robić, aby zainicjować tryb failover strefy.
  • Powiadomienie: firma Microsoft nie powiadamia cię automatycznie, gdy strefa nie działa. Możesz jednak użyć usługi Azure Service Health , aby zrozumieć ogólną kondycję usługi, w tym wszelkie błędy strefy, i skonfigurować alerty usługi Service Health w celu powiadamiania o problemach.
  • Aktywne żądania: Gdy strefa dostępności przejdzie w tryb offline, wszystkie żądania przetwarzane w uszkodzonej strefie dostępności zostaną zakończone i muszą zostać ponowione. Aby uzyskać więcej informacji na temat sposobu, aby aplikacje były odporne na te typy problemów, zobacz Wskazówki dotyczące odporności na błędy przejściowe .

  • Przekierowywanie ruchu: W przypadku warstwy usługi Ogólnego przeznaczenia usługa SQL Database przenosi aparat bazy danych do innego bezstanowego węzła obliczeniowego, który znajduje się w innej strefie dostępności i ma wystarczającą ilość wolnej pojemności. Po zakończeniu pracy w trybie failover nowe połączenia są automatycznie przekierowywane do nowego podstawowego węzła obliczeniowego.

    Aby uzyskać więcej informacji, zobacz Warstwa usługi ogólnego przeznaczenia.

  • Przekierowywanie ruchu: W przypadku poziomów usług Premium i Krytyczne dla Biznesu, usługa SQL Database wybiera replikę w innej strefie dostępności, aby stać się repliką podstawową. Gdy replika wtórna stanie się nową repliką podstawową, zostanie utworzona kolejna replika wtórna, aby upewnić się, że klaster ma wystarczającą liczbę replik do utrzymania kworum. Po zakończeniu pracy w trybie failover nowe połączenia są automatycznie przekierowywane do nowej repliki podstawowej (lub repliki pomocniczej z możliwością odczytu na podstawie parametrów połączenia).

    Aby uzyskać więcej informacji, zobacz Warstwy usług Premium i Krytyczne dla działania firmy.

  • Przekierowywanie ruchu: W przypadku warstwy usługi Hiperskala, jeśli replika podstawowa została utracona z powodu awarii strefy, usługa SQL Database promuje jedną z replik wysokiej dostępności w innej strefie jako nową podstawową.

    Aby uzyskać więcej informacji, zobacz Warstwa usługi Hiperskala.

  • Oczekiwany przestój: Podczas przełączania strefy dostępności w tryb failover może wystąpić niewielki przestój. Przestój jest zwykle krótszy niż 30 sekund, co aplikacja powinna tolerować, jeśli jest zgodna ze wskazówkami dotyczącymi odporności na błędy przejściowe .

  • Oczekiwana utrata danych: Brak oczekiwanej utraty danych podczas pracy w trybie failover strefy dostępności.

Aby wyświetlić informacje o obsłudze strefy dostępności dla innych warstw usług, należy wybrać odpowiednią warstwę usługi na początku tej strony.

Odzyskiwanie strefy

Po odzyskaniu strefy dostępności usługa Azure Service Fabric automatycznie tworzy repliki bazy danych w odzyskanej strefie dostępności, usuwa wszystkie tymczasowe repliki utworzone w innych strefach dostępności i wznawia routing ruchu normalnego do bazy danych. Aby uniknąć zakłóceń, replika podstawowa nie zwraca automatycznie oryginalnej strefy po odzyskiwaniu strefy.

Testowanie pod kątem niepowodzeń strefy

Platforma SQL Database zarządza procedurami trasowania ruchu, awaryjnego przełączania i odtwarzania strefowego dla strefowo nadmiarowych baz danych. Ponieważ ta funkcja jest w pełni zarządzana, nie trzeba inicjować ani weryfikować procesów awarii strefy dostępności. Można jednak zweryfikować obsługę awarii i trybu failover aplikacji, wykonując proces opisany w artykule Testowanie odporności błędów aplikacji.

Odporność na awarie całego regionu

Ta sekcja zawiera omówienie dwóch powiązanych, ale oddzielnych funkcji, które mogą być używane do replikacji geograficznej usługi SQL Database w wielu regionach:

Aktywna replikacja geograficzna

Aktywna replikacja geograficzna tworzy stale synchronizowaną odczytywalną pomocniczą bazę danych (czasami nazywaną geo-pomocniczą lub geo-repliką) w dowolnym regionie dla pojedynczej podstawowej bazy danych. Aktywna replikacja geograficzna może tworzyć pomocnicze bazy danych w tym samym regionie, ale ta konfiguracja nie zapewnia ochrony przed awarią regionu. W przypadku korzystania z aktywnej replikacji geograficznej w celu uzyskania nadmiarowości geograficznej należy zlokalizować pomocniczą bazę danych w innym regionie do podstawowej bazy danych.

Requirements

W przypadku korzystania z aktywnej replikacji geograficznej należy wziąć pod uwagę następujące wymagania:

  • Obsługa regionów: Aktywna replikacja geograficzna może być włączona we wszystkich regionach świadczenia usługi Azure i nie wymaga używania par regionów platformy Azure.

    Wskazówka

    Usługa SQL Database jest zgodna z bezpieczną praktyką wdrażania, w której platforma Azure nie dąży do wdrażania aktualizacji w sparowanych regionach w tym samym czasie. Jeśli skonfigurujesz aktywną replikację geograficzną tak, aby korzystała z niepairowanych regionów, ustaw różne okna obsługi dla serwerów w każdym regionie. Takie podejście pomaga zmniejszyć prawdopodobieństwo wystąpienia problemów z łącznością w obu regionach spowodowanych przez konserwację w tym samym czasie.

  • Konfiguracja: Zarówno podstawowa warstwa usługi, jak i geograficzna warstwa pomocnicza muszą mieć tę samą warstwę usługi i powinny mieć tę samą warstwę obliczeniową, rozmiar obliczeniowy i nadmiarowość magazynu kopii zapasowych.

  • Zapory: Zarówno podstawowa, jak i geograficznie-sekundarna powinna mieć te same reguły zapory dla adresów IP.

  • Subskrypcje platformy Azure: Aktywna replikacja geograficzna jest obsługiwana w przypadku baz danych w różnych subskrypcjach platformy Azure.

Rozważania

  • Aktywna replikacja geograficzna została zaprojektowana w celu zapewnienia przełączenia awaryjnego pojedynczej bazy danych. Jeśli musisz przełączyć wiele baz danych do trybu failover, rozważ użycie grup failover.

  • Ponieważ replikacja geograficzna jest asynchroniczna, utrata danych jest możliwa w przypadku przejścia w tryb failover. Jeśli musisz wyeliminować utratę danych z replikacji asynchronicznej podczas pracy w trybie failover, skonfiguruj aplikację, aby zablokować wątek wywołujący do momentu przesyłania i wzmacniania zabezpieczeń ostatniej zatwierdzonej transakcji w dzienniku transakcji pomocniczej bazy danych. Takie podejście wymaga tworzenia niestandardowego i zmniejsza wydajność aplikacji. Aby uzyskać więcej informacji, zobacz Zapobieganie utracie krytycznych danych.

  • Aby uzyskać więcej informacji na temat ograniczeń i zagadnień, zobacz Aktywna replikacja geograficzna.

Koszt

Pomocnicze bazy danych są rozliczane jako oddzielne bazy danych.

Jeśli nie używasz pomocniczej bazy danych dla obciążeń odczytu lub zapisu, rozważ, czy można wyznaczyć ją jako replikę rezerwową , aby zmniejszyć koszty.

Konfigurowanie obsługi wielu regionów

Zachowanie, gdy wszystkie regiony są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać, gdy baza danych jest skonfigurowana do korzystania z aktywnej replikacji geograficznej, a wszystkie regiony działają.

  • Routing ruchu między regionami: Aplikacja musi być skonfigurowana do wysyłania żądań odczytu i zapisu do podstawowej bazy danych. Opcjonalnie można wysyłać żądania tylko do odczytu do pomocniczej bazy danych, co pomaga zmniejszyć wpływ obciążeń tylko do odczytu w podstawowej bazie danych.

  • Replikacja danych między regionami: Replikacja między podstawowymi i pomocniczymi bazami danych odbywa się asynchronicznie, co oznacza, że może wystąpić opóźnienie między chwilą zastosowania zmiany do podstawowej bazy danych i replikacji do pomocniczej bazy danych.

    Podczas przechodzenia w tryb failover decydujesz, jak obsłużyć możliwość utraty danych.

Zachowanie podczas awarii regionu

W tej sekcji opisano, czego można oczekiwać, gdy baza danych jest skonfigurowana do korzystania z aktywnej replikacji geograficznej i występuje awaria w regionie podstawowym:

  • Wykrywanie i reagowanie: Odpowiadasz za wykrywanie awarii bazy danych lub regionu oraz wyzwalanie trybu failover.
  • Powiadomienie: firma Microsoft nie powiadamia cię automatycznie, gdy region nie działa. Możesz jednak użyć usługi Azure Service Health , aby zrozumieć ogólną kondycję usługi, w tym wszelkie awarie regionów, i skonfigurować alerty usługi Service Health w celu powiadamiania o problemach.

  • Aktywne żądania: Wszystkie aktywne żądania podczas pracy w trybie failover są przerywane i muszą zostać ponowione.

  • Oczekiwana utrata danych: Jeśli podstawowa baza danych jest dostępna, możesz opcjonalnie wykonać tryb failover bez utraty danych. Proces failover synchronizuje dane między głównymi a zapasowymi bazami danych przed przełączeniem ról.

    Jeśli podstawowa baza danych jest niedostępna, może być konieczne przeprowadzenie wymuszonego przejścia w tryb failover, co powoduje utratę danych. Możesz oszacować ilość utraty danych, monitorując opóźnienie replikacji. Aby uzyskać więcej informacji, zobacz Monitorowanie usługi SQL Database przy użyciu metryk i alertów.

  • Oczekiwany przestój: Zazwyczaj podczas pracy w trybie failover występuje do 60 sekund przestojów. Upewnij się, że aplikacja obsługuje błędy przejściowe , aby mogła odzyskać sprawność po krótkich okresach przestojów. Ponadto szybkość ponownego konfigurowania aplikacji w celu nawiązania połączenia z nową podstawową bazą danych wpływa na przestoje, które występują.

  • Przekierowywanie ruchu: Odpowiadasz za ponowne skonfigurowanie aplikacji w celu wysyłania żądań do nowej podstawowej bazy danych. Jeśli potrzebujesz przezroczystego trybu failover, rozważ użycie grup trybu failover.

Odzyskiwanie regionów

Po przywróceniu regionu podstawowego możesz ręcznie wykonać przywrócenie działania do regionu podstawowego, przeprowadzając kolejne przełączenie awaryjne.

Testowanie pod kątem błędów regionów

Można zasymulować przerwę w działaniu regionu, wyzwalając ręczne przełączenie awaryjne w dowolnym momencie. Możesz wyzwolić przełączenie awaryjne bez utraty danych lub wymuszone przełączenie awaryjne.

Grupy trybu failover

Grupy failover są oparte na aktywnej replikacji geograficznej. W przypadku grup przełączania awaryjnego można wykonywać następujące operacje:

  • Replikowanie zestawu baz danych z pojedynczego serwera logicznego w dowolnej kombinacji regionów świadczenia usługi Azure.

  • Przeprowadź failover dla baz danych jako grupy.

  • Używaj punktów końcowych połączenia, które automatycznie kierują połączenia do serwera podstawowego.

Requirements

  • Obsługa regionów: Grupy trybu failover można tworzyć we wszystkich regionach świadczenia usługi Azure i nie wymagają używania par regionów platformy Azure.

    Wskazówka

    Jeśli skonfigurujesz grupę przełączania awaryjnego z niezsynchronizowanymi regionami, rozważ ustawienie różnych okien obsługi dla serwerów w każdym regionie. Takie podejście pomaga zmniejszyć prawdopodobieństwo wystąpienia problemów z łącznością w obu regionach spowodowanych przez konserwację w tym samym czasie.

  • Konfiguracja: Pomocnicze bazy danych w grupie przełączeniowej powinny mieć tę samą warstwę usługi, warstwę obliczeniową, rozmiar obliczeniowy, reguły zapory adresów IP i nadmiarowość magazynu kopii zapasowych co podstawowa baza danych.

Rozważania

  • Nadmiarowość strefy: W przypadku warstwy usługi Hiperskala, jeśli podstawowa baza danych ma włączoną nadmiarowość strefy, pomocnicze bazy danych mają automatycznie włączoną nadmiarowość strefy.
  • Nadmiarowość strefy: Pomocnicze bazy danych nie mają domyślnie włączonej nadmiarowości strefy, ale można ją włączyć później.

  • Możliwa utrata danych: Ponieważ replikacja geograficzna jest asynchroniczna, istnieje możliwość utraty danych w przypadku przejścia w tryb failover. Jeśli musisz wyeliminować utratę danych z replikacji asynchronicznej podczas failoverów, możesz skonfigurować aplikację, aby zablokować wątek wywołujący do momentu, gdy ostatnia zatwierdzona transakcja zostanie przesłana i utrwalona w dzienniku transakcji bazy danych podrzędnej. Takie podejście wymaga tworzenia niestandardowego i zmniejsza wydajność aplikacji. Aby uzyskać więcej informacji, zobacz Zapobieganie utracie krytycznych danych.

  • Aby uzyskać więcej informacji na temat ograniczeń i zagadnień, zobacz Grupy przełączania awaryjnego.

Koszt

Pomocnicze bazy danych są rozliczane jako oddzielne bazy danych.

Jeśli nie używasz pomocniczej bazy danych dla obciążeń odczytu lub zapisu, rozważ, czy można wyznaczyć ją jako replikę rezerwową , aby zmniejszyć koszty.

Konfigurowanie obsługi wielu regionów

  • Włącz grupy przełączania awaryjnego: Grupę przełączania awaryjnego można skonfigurować na serwerze logicznym. Możesz dodać wszystkie bazy danych na serwerze logicznym do grupy trybu przełączania awaryjnego lub wybrać podzbiór baz danych do dodania.

    Podczas tworzenia grupy trybu failover należy wybrać zasady trybu failover, które określają, kto jest odpowiedzialny za wykrywanie awarii i wykonywanie trybu failover. Możesz skonfigurować tryb failover zarządzany przez klienta, co jest zalecane, lub tryb failover zarządzany przez firmę Microsoft.

    Ważne

    Przełączenie w tryb failover zainicjowane przez firmę Microsoft może wystąpić po znacznym opóźnieniu i jest wykonywane w oparciu o maksymalne starania. Przełączenie w tryb awaryjny baz danych może wystąpić w innym czasie niż przełączenie w tryb awaryjny innych usług platformy Azure. Aby uzyskać więcej informacji, zobacz Konfigurowanie grupy trybu failover dla usługi SQL Database.

    Po skonfigurowaniu grupy przełączania awaryjnego początkowy krok inicjacji może zająć trochę czasu.

  • Wyłącz grupy trybu failover: Pojedynczą bazę danych można usunąć z grupy trybu failover, usunąć całą grupę trybu failover lub przenieść bazę danych do innej grupy trybu failover.

Zachowanie, gdy wszystkie regiony są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać, gdy baza danych jest skonfigurowana w grupie trybu failover, a wszystkie regiony działają.

  • Routing ruchu między regionami: W przypadku obciążeń odczytu i zapisu oraz obciążeń tylko do odczytu, grupy failover udostępniają dwa końcowe punkty odbiorcze, do których można podłączyć aplikacje. Użyj punktów końcowych odbiornika grupy przełączania awaryjnego, aby zminimalizować przestoje podczas przełączania awaryjnego. Podczas normalnych operacji występuje następujące zachowanie routingu:

    • Punkt końcowy odbiornika odczytu i zapisu kieruje wszystkie żądania do podstawowych baz danych.

    • Punkt końcowy odbiornika tylko do odczytu kieruje wszystkie żądania do pomocniczej bazy danych z możliwością odczytu.

  • Replikacja danych między regionami: Replikacja geograficzna między podstawowymi i pomocniczymi bazami danych odbywa się asynchronicznie. To opóźnienie oznacza, że może wystąpić opóźnienie między zmianą zastosowaną do podstawowej bazy danych a replikacją do pomocniczej bazy danych.

    Podczas przechodzenia w tryb failover decydujesz, jak obsłużyć możliwość utraty danych.

Zachowanie podczas awarii regionu

W tej sekcji opisano, czego można oczekiwać po skonfigurowaniu bazy danych w grupie trybu failover i awarii w regionie podstawowym:

  • Wykrywanie i reagowanie zależy od używanych zasad trybu failover.

    • Tryb failover zainicjowany przez klienta: Odpowiadasz za wykrywanie awarii bazy danych lub regionu oraz wyzwalanie trybu failover.

    • Failover zainicjowany przez firmę Microsoft: Firma Microsoft wywołuje tryb failover dla wszystkich grup w dotkniętym regionie. Firma Microsoft oczekuje, że ten typ trybu failover będzie działać tylko w wyjątkowych sytuacjach. W przypadku większości rozwiązań nie należy polegać na trybie failover zarządzanym przez firmę Microsoft. Aby uzyskać więcej informacji, zobacz Zasady trybu failover — zarządzane przez firmę Microsoft.

  • Powiadomienie: firma Microsoft nie powiadamia cię automatycznie, gdy region nie działa. Możesz jednak użyć usługi Azure Service Health , aby zrozumieć ogólną kondycję usługi, w tym wszelkie awarie regionów, i skonfigurować alerty usługi Service Health w celu powiadamiania o problemach.

  • Aktywne żądania: Wszystkie aktywne żądania podczas pracy w trybie failover są przerywane i muszą zostać ponowione.

  • Oczekiwana utrata danych: Utrata danych zależy od używanych zasad trybu failover.

    • Tryb failover zainicjowany przez klienta: Jeśli podstawowa baza danych jest dostępna, możesz opcjonalnie wykonać tryb failover bez utraty danych. Proces failover synchronizuje dane między głównymi a zapasowymi bazami danych przed przełączeniem ról.

      Jeśli podstawowa baza danych jest niedostępna, może być konieczne przeprowadzenie wymuszonego przejścia w tryb failover, co powoduje utratę danych. Możesz oszacować ilość utraty danych, monitorując opóźnienie replikacji. Aby uzyskać więcej informacji, zobacz Monitorowanie usługi SQL Database przy użyciu metryk i alertów.

    • Failover zainicjowany przez firmę Microsoft: Failover zarządzany przez firmę Microsoft jest wyzwalany tylko w wyjątkowych sytuacjach. Zarządzane przez Microsoft tryby failover są wymuszone, co oznacza, że jest spodziewana utrata danych. Nie można kontrolować ilości utraty danych, które mogą wystąpić.

  • Oczekiwany przestój: Przestój zależy od używanych zasad trybu failover.

    • Tryb failover zainicjowany przez klienta: Zazwyczaj podczas pracy w trybie failover występuje do 60 sekund przestojów. Upewnij się, że aplikacja obsługuje błędy przejściowe , aby mogła odzyskać sprawność po krótkich okresach przestojów.

    • Tryb failover zainicjowany przez firmę Microsoft: Możesz określić okres prolongaty , który określa, jak długo firma Microsoft powinna czekać przed zainicjowaniem trybu failover. Minimalny okres prolongaty to jedna godzina. Jednak czas odpowiedzi firmy Microsoft prawdopodobnie potrwa co najmniej kilka godzin.

  • Przekierowywanie ruchu: Podczas pracy w trybie failover usługa SQL Database aktualizuje punkty końcowe odbiorcy do odczytu i zapisu oraz tylko do odczytu, aby kierować ruch zgodnie z potrzebami do nowych baz danych podstawowych i pomocniczych.

    Jeśli nowa pomocnicza baza danych (wcześniej podstawowa baza danych) nie jest dostępna, punkt końcowy odbiornika tylko do odczytu nie może nawiązać połączenia, dopóki nie będzie dostępny nowy pomocniczy.

Odzyskiwanie regionów

Jeśli musisz to zrobić, odpowiadasz za przywrócenie działania w regionie podstawowym. Powrót po awarii do regionu podstawowego można wykonać ręcznie, wykonując tryb failover zarządzany przez klienta.

Nawet jeśli firma Microsoft zainicjowała procedurę przełączenia awaryjnego, nadal ponosisz odpowiedzialność za przeprowadzenie procedury przełączenia powrotnego do poprzedniego regionu, jeśli zdecydujesz się na to.

Testowanie pod kątem błędów regionów

Można zasymulować przerwę w działaniu regionu, wyzwalając ręczne przełączenie awaryjne w dowolnym momencie. Możesz wyzwolić przełączenie awaryjne bez utraty danych lub wymuszone przełączenie awaryjne.

Tworzenie kopii zapasowej i przywracanie

Wykonywanie kopii zapasowych baz danych w celu ochrony przed różnymi zagrożeniami, w tym utratą danych. Kopie zapasowe można przywrócić w celu odzyskania po przypadkowej utracie danych, uszkodzeniu lub innych problemach. Kopie bezpieczeństwa różnią się od strefowej nadmiarowości, aktywnej replikacji geograficznej lub grup awaryjnego przełączania i mają różne cele. Aby uzyskać więcej informacji, zobacz Nadmiarowość, replikacja i kopia zapasowa.

Usługa SQL Database udostępnia automatyczne kopie zapasowe baz danych. Aby uzyskać więcej informacji na temat częstotliwości tworzenia kopii zapasowych, co może mieć wpływ na ilość utraty danych w razie potrzeby przywrócenia z kopii zapasowej, zobacz Automatyczne kopie zapasowe w usłudze SQL Database.

Magazyn kopii zapasowych

Możesz przechowywać automatyczne kopie zapasowe w LRS lub ZRS. Jeśli używasz sparowanego regionu, możesz wybrać replikację automatycznych kopii zapasowych do sparowanego regionu przy użyciu magazynu geograficznie nadmiarowego. Funkcja ta umożliwia przywracanie kopii zapasowych do sparowanego regionu geograficznego. Aby uzyskać więcej informacji, zobacz Automatyczne kopie zapasowe w usłudze SQL Database.

Jeśli korzystasz z niesparowanego regionu lub jeśli chcesz replikować kopie zapasowe do regionu innego niż sparowany region, rozważ wyeksportowanie bazy danych i zapisanie wyeksportowanego pliku na koncie magazynu, które używa replikacji obiektów blob na konto magazynu w innym regionie. Aby uzyskać więcej informacji, zobacz Eksportowanie bazy danych.

Odporność usługi na prace konserwacyjne

Gdy usługa SQL Database wykonuje konserwację baz danych i pul elastycznych, może automatycznie przełączyć bazę danych do stanu failover, aby użyć repliki zapasowej. Aplikacje klienckie mogą obserwować krótkie przerwy w łączności w przypadku przejścia w tryb failover. Aplikacje klienckie powinny postępować zgodnie ze wskazówkami dotyczącymi odporności na błędy przejściowe , aby zminimalizować skutki.

Usługa SQL Database umożliwia określenie okna obsługi, które jest zwykle używane na potrzeby uaktualnień usług i innych operacji konserwacji. Skonfigurowanie okna obsługi może pomóc zminimalizować wszelkie skutki uboczne, takie jak automatyczne przełączanie w tryb failover, w godzinach pracy. Możesz również otrzymywać powiadomienia z wyprzedzeniem o planowanej konserwacji.

Platforma automatycznie utrzymuje bramy używane do przetwarzania połączeń z usługą SQL Database. Uaktualnienia lub operacje konserwacji mogą również powodować krótkie zakłócenia łączności, które klienci mogą ponowić.

Aby uzyskać więcej informacji, zobacz Okno obsługi w usłudze SQL Database.

Umowa dotycząca poziomu usług

Umowa dotycząca poziomu usług (SLA) dla usług platformy Azure opisuje oczekiwaną dostępność każdej usługi oraz warunki, które rozwiązanie musi spełnić, aby osiągnąć te oczekiwania dotyczące dostępności. Aby uzyskać więcej informacji, zobacz Umowy SLA dotyczące usług online.

Umowa dotycząca poziomu usług (SLA) dla usługi SQL Database opisuje oczekiwaną dostępność usługi oraz oczekiwany punkt odzyskiwania i czas odzyskiwania dla aktywnej replikacji geograficznej.

W przypadku wdrożenia bazy danych lub puli elastycznej z obsługą redundancji strefowej przy użyciu obsługiwanego poziomu usług, umowa SLA będzie wyższa.

Treści powiązane

  • Last updated on