Udostępnij przez

Niezawodność w usłudze Azure SQL Managed Instance

Azure SQL Managed Instance to w pełni zarządzany aparat bazy danych jako usługa platformy (PaaS). Zapewnia ona prawie 100% zgodność funkcji z programem SQL Server. Usługa Azure SQL Managed Instance obsługuje większość funkcji zarządzania bazami danych, takich jak uaktualnianie, stosowanie poprawek, tworzenie kopii zapasowych i monitorowanie bez udziału użytkownika. Działa na najnowszej stabilnej wersji silnika bazy danych SQL Server oraz załatanym systemie operacyjnym z wbudowaną wysoką dostępnością.

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 możliwości we wszystkich używanych usługach oraz wybór możliwości potrzebnych do osiągnięcia twoich celów biznesowych i celów dostępności.

W tym artykule opisano, jak usługa Azure SQL Managed Instance 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ługi i wyróżnia niektóre kluczowe informacje o umowie dotyczącej poziomu usług (SLA) usługi Azure SQL Managed Instance.

Zalecenia dotyczące wdrażania produkcyjnego pod kątem niezawodności

W przypadku większości wdrożeń produkcyjnych usługi SQL Managed Instance należy wziąć pod uwagę następujące zalecenia:

Omówienie architektury niezawodności

Zarządzane wystąpienia SQL ogólnego przeznaczenia działają na jednym węźle, którymi zarządza usługa Azure Service Fabric. Za każdym razem, gdy aparat bazy danych lub system operacyjny zostanie uaktualniony lub zostanie wykryty błąd, usługa SQL Managed Instance współpracuje z usługą Service Fabric w celu przeniesienia bezstanowego procesu aparatu bazy danych do innego bezstanowego węzła obliczeniowego, który ma wystarczającą ilość wolnej pojemności. Pliki bazy danych są przechowywane w usłudze Azure Blob Storage, która ma wbudowane funkcje nadmiarowości. Pliki danych i dziennika są odłączone od oryginalnego węzła obliczeniowego i dołączone do nowo zainicjowanego procesu aparatu bazy danych.

Wystąpienia zarządzane SQL krytyczne dla działania firmy używają wielu replik w klastrze. Klaster zawiera dwa typy replik:

  • Pojedyncza replika podstawowa, która może być dostępna dla obciążeń związanych z odczytem i zapisem na potrzeby klientów.

  • Maksymalnie pięć replik pomocniczych (obliczeniowych i magazynowych), które zawierają kopie danych

Replika podstawowa stale i sekwencyjnie wypycha zmiany do replik pomocniczych, co gwarantuje, że dane są utrwalane na wystarczającej liczbie replik pomocniczych przed zatwierdzeniem każdej transakcji. Ten proces gwarantuje, że jeśli replika podstawowa lub czytelna replika pomocnicza staną się niedostępne, zawsze dostępna jest w pełni zsynchronizowana replika do przełączenia awaryjnego.

Instancja zarządzana SQL i Service Fabric inicjują failover między replikami. Gdy replika pomocnicza stanie się nową repliką podstawową, zostanie utworzona inna replika pomocnicza, aby upewnić się, że klaster ma wystarczającą liczbę replik do obsługi kworum. Po zakończeniu pracy w trybie failover połączenia usługi Azure SQL są automatycznie przekierowywane do nowej repliki podstawowej lub repliki pomocniczej z możliwością odczytu na podstawie parametrów połączenia.

Redundancja

Domyślnie usługa SQL Managed Instance osiąga nadmiarowość przez rozłożenie węzłów obliczeniowych i danych w jednym centrum danych w regionie podstawowym. Takie podejście chroni dane podczas następujących oczekiwanych i nieoczekiwanych przestojów:

  • Operacje zarządzania inicjowane przez klienta, które powodują krótki przestój

  • Operacje konserwacji usługi

  • Awarie sieci lub zasilania na małą skalę

  • Problemy i awarie centrum danych, które obejmują następujące składniki:

    • Rack, w którym działają maszyny obsługujące twoją usługę

    • Maszyna fizyczna, która hostuje maszynę wirtualną uruchamiającą silnik bazy danych SQL.

    • Maszyna VM z uruchomionym aparatem bazy danych SQL

  • Problemy z silnikiem bazy danych SQL

  • Potencjalne nieplanowane zlokalizowane awarie

Aby uzyskać więcej informacji na temat zapewniania nadmiarowości przez usługę SQL Managed Instance, zobacz Dostępność za pośrednictwem nadmiarowości lokalnej i strefowej.

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.

Wystąpienie zarządzane SQL automatycznie obsługuje krytyczne zadania serwisowe, takie jak stosowanie poprawek, kopie zapasowe oraz uaktualnienia systemu Windows i silnika bazy danych SQL. Obsługuje również nieplanowane zdarzenia, takie jak awarie sprzętu, oprogramowania lub sieci bazowej. Instancja zarządzana SQL może szybko odzyskiwać nawet w najbardziej krytycznych okolicznościach, zapewniając, że Twoje dane są zawsze dostępne. Większość użytkowników nie zauważa, że uaktualnienia są wykonywane w sposób ciągły.

Jeśli wystąpienie jest poprawiane lub przechodzi w tryb failover, przestój ma minimalny wpływ w przypadku zastosowania logiki ponawiania prób w aplikacji. Odporność aplikacji można przetestować na błędy przejściowe.

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

Uwaga / Notatka

Redundancja strefy nie jest obecnie dostępna dla warstwy usługi o ogólnym przeznaczeniu następnej generacji.

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.

Po włączeniu konfiguracji strefowo nadmiarowej można upewnić się, że wystąpienie zarządzane SQL jest odporne na duży zestaw awarii, w tym katastrofalne awarie centrum danych, bez żadnych zmian logiki aplikacji.

Usługa SQL Managed Instance umożliwia osiągnięcie nadmiarowości strefy przez umieszczenie bezstanowych węzłów obliczeniowych w różnych strefach dostępności. Opiera się on na stanowym ZRS związanym z węzłem, który aktualnie zawiera aktywny proces mechanizmu bazy danych SQL. Jeśli wystąpi awaria, proces modułu bazy danych SQL staje się aktywny w jednym z bezstanowych węzłów obliczeniowych, który następnie uzyskuje dostęp do danych w magazynie stanowym.

Usługa SQL Managed Instance osiąga strefową nadmiarowość, umieszczając repliki zarządzanego wystąpienia SQL w wielu strefach dostępności. Aby wyeliminować pojedynczy punkt awarii, pierścień sterowania jest również duplikowany w wielu strefach. Ruch płaszczyzny sterowania jest kierowany do modułu równoważenia obciążenia, który jest również wdrażany w różnych strefach dostępności. Usługa Azure Traffic Manager zarządza trasowaniem ruchu z płaszczyzny kontrolnej do modułu równoważenia obciążenia.

Requirements

  • Obsługa regionów: Strefowa nadmiarowość dla usługi zarządzanej SQL Managed Instance jest obsługiwana w wybranych regionach. Aby uzyskać więcej informacji, zobacz Obsługiwane regiony.

  • Redundancja magazynu kopii zapasowych: Aby włączyć nadmiarowość strefową dla wystąpienia zarządzanego SQL, ustaw redundancję magazynu kopii zapasowych na ZRS lub Geograficznie Nadmiarowy Magazyn Strefowy (GZRS).

Koszt

Po włączeniu nadmiarowości strefowej istnieje dodatkowy koszt zarówno dla zarządzanego wystąpienia SQL, jak i dla kopii zapasowych nadmiarowych z obsługą strefową. Aby uzyskać więcej informacji, zobacz Cennik.

Możesz zaoszczędzić pieniądze, zobowiązując się do korzystania z zasobów obliczeniowych w obniżonej cenie przez pewien czas, w tym wystąpienia strefowo nadmiarowe w warstwie usługi Krytyczne dla działania firmy. Aby uzyskać więcej informacji, zobacz Rezerwacje dla usługi SQL Managed Instance.

Konfiguruj obsługę stref dostępności

W tej sekcji opisano sposób konfigurowania obsługi stref dostępności dla wystąpień zarządzanych SQL:

  • Włącz nadmiarowość strefy: Aby dowiedzieć się, jak skonfigurować nadmiarowość strefy w nowych i istniejących wystąpieniach, zobacz Konfigurowanie nadmiarowości strefy.

    Wszystkie operacje skalowania dla usługi SQL Managed Instance, w tym włączanie redundancji strefy, to operacje online i wymagają minimalnego lub żadnego przestoju. Aby uzyskać więcej informacji, zobacz Czas trwania operacji zarządzania.

  • Wyłącz nadmiarowość strefy: Nadmiarowość strefy można wyłączyć, wykonując te same kroki, aby włączyć nadmiarowość strefy. Ten proces jest operacją online podobną do zwykłego uaktualnienia celu warstwy usług. Na końcu procesu wystąpienie jest migrowane z infrastruktury strefowo nadmiarowej do infrastruktury jednostrefowej.

Zachowanie, gdy wszystkie strefy są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać, kiedy zarządzana instancja SQL jest skonfigurowana z myślą o strefowej nadmiarowości i wszystkie strefy dostępności są operacyjne.

  • Routing ruchu między strefami: Podczas normalnych operacji żądania są kierowane do węzła z uruchomioną warstwą obliczeniową usługi SQL Managed Instance.

  • Replikacja danych między strefami: Pliki bazy danych są przechowywane w Azure Storage za pomocą ZRS, który jest podłączony do węzła, który obecnie zawiera aktywny proces aparatu bazy danych SQL.

    Operacje zapisu są synchroniczne i nie są uznawane za ukończone, dopóki dane nie zostaną pomyślnie zreplikowane 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.

  • Routing ruchu między strefami: Podczas normalnych operacji żądania są kierowane do podstawowej repliki wystąpienia zarządzanego SQL.

  • Replikacja danych między strefami: Replika podstawowa stale i sekwencyjnie wypycha zmiany do replik pomocniczych w różnych strefach dostępności. Ten proces gwarantuje, że dane są utrwalane na wystarczającej liczbie replik pomocniczych przed zatwierdzeniem każdej transakcji. Te repliki znajdują się w różnych strefach dostępności. 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.

    Ze względu na to, że instancje z redundancją strefową mają repliki w różnych centrach danych znajdujących się w pewnej odległości, zwiększone opóźnienie sieciowe może wydłużyć czas zatwierdzania transakcji. Ten wzrost może mieć wpływ na wydajność niektórych obciążeń przetwarzania transakcji online (OLTP). Większość aplikacji nie jest wrażliwa na to dodatkowe opóźnienie.

Zachowanie podczas awarii strefy

W tej sekcji opisano, czego można oczekiwać, gdy wystąpienie zarządzane SQL jest skonfigurowane jako strefowo redundantne, a co najmniej jedna strefa dostępności jest niedostępna.

  • Wykrywanie i reagowanie: Usługa SQL Managed Instance jest odpowiedzialna za wykrywanie awarii i reagowanie na nie w strefie dostępności. Nie musisz nic robić, aby zainicjować tryb failover strefy.
  • Aktywne żądania: Gdy strefa dostępności jest niedostępna, wszystkie żądania przetwarzane w uszkodzonej strefie dostępności zostaną zakończone i muszą zostać ponowione. Aby zapewnić odporność aplikacji na te typy problemów, zobacz Wskazówki dotyczące odporności na błędy przejściowe .

  • Przekierowywanie ruchu: Usługa SQL Managed Instance współpracuje z usługą Service Fabric w celu przeniesienia aparatu bazy danych do odpowiedniego 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.

    Duże obciążenie może spowodować obniżenie wydajności podczas przejścia z jednego węzła obliczeniowego do drugiego węzła obliczeniowego, ponieważ nowy proces aparatu bazy danych rozpoczyna się od zimnej pamięci podręcznej.

  • Przekierowywanie ruchu: Usługa SQL Managed Instance współpracuje z usługą Service Fabric, aby wybrać odpowiednią replikę w innej strefie dostępności, aby stać się repliką podstawową. Gdy replika pomocnicza stanie się nową repliką podstawową, zostanie utworzona inna replika pomocnicza, aby upewnić się, że klaster ma wystarczającą liczbę replik do obsługi 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.

  • 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: Nie oczekuje się utraty danych dla zatwierdzonych transakcji podczas pracy w strefie dostępności w trybie failover. Transakcje w toku muszą zostać ponowione.

Odzyskiwanie strefy

Gdy strefa dostępności zostanie odzyskana, usługa SQL Managed Instance współpracuje z usługą Service Fabric w celu przywrócenia operacji w odzyskanej strefie. Żadna interwencja klienta nie jest wymagana.

Testowanie pod kątem niepowodzeń strefy

Platforma SQL Managed Instance zarządza routingiem ruchu, przełączeniami awaryjnymi i powrotami po awarii dla wystąpień z nadmiarowością strefową. 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ę błędów aplikacji.

Odporność na awarie całego regionu

Pojedyncze wystąpienie zarządzane SQL jest wdrażane w jednym regionie. Można jednak wdrożyć pomocnicze wystąpienie zarządzane SQL w osobnym regionie świadczenia usługi Azure i skonfigurować grupę trybu failover.

Grupy trybu failover

Grupy trybu failover automatycznie replikują geograficznie dane i mogą automatycznie lub ręcznie przejść w tryb failover w przypadku wystąpienia awarii regionalnej na podstawie zasad trybu failover.

Ta sekcja zawiera podsumowanie kluczowych informacji o grupach trybu failover, ale ważne jest, aby zapoznać się z omówieniem grup trybu failover i najlepszymi rozwiązaniami , aby dowiedzieć się więcej na temat sposobu ich działania i sposobu ich konfigurowania.

Zasady trybu failover

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żna skonfigurować dwa typy zasad trybu failover:

  • Tryb failover zarządzany przez klienta (zalecane): W przypadku korzystania z zasad trybu failover zarządzanego przez klienta możesz zdecydować, czy przeprowadzić tryb failover, który nie powoduje utraty danych, czy wymuszonego przejścia w tryb failover, co może spowodować utratę danych. Wymuszone przełączanie awaryjne jest używane jako metoda odzyskiwania podczas awarii, gdy nie można uzyskać dostępu do instancji głównej.

  • Tryb failover zarządzany przez firmę Microsoft: Tryb failover zarządzany przez firmę Microsoft jest używany tylko w wyjątkowych sytuacjach w celu wyzwolenia wymuszonego przejścia w tryb failover.

Ważne

Użyj opcji failover zarządzanej przez klienta, aby opracowywać, testować i implementować plany odzyskiwania po awarii. Nie należy polegać na trybie failover zarządzanym przez firmę Microsoft, który może być używany tylko w ekstremalnych okolicznościach. Tryb failover zarządzany przez firmę Microsoft prawdopodobnie jest inicjowany dla całego regionu. Nie można zainicjować jej dla poszczególnych grup trybu failover, wystąpień zarządzanych SQL, subskrypcji ani klientów. Przełączenie awaryjne może wystąpić w różnym czasie dla różnych usług Azure. Zalecamy korzystanie z trybu failover zarządzanego przez klienta.

Obsługa regionów

Możesz wybrać dowolny region świadczenia usługi Azure dla wystąpień zarządzanych SQL w grupie trybu failover. Ze względu na duże opóźnienia sieci rozległe replikacja geograficzna używa mechanizmu replikacji asynchronicznej. Aby zmniejszyć opóźnienia sieci, wybierz regiony z małymi opóźnieniami. Aby uzyskać więcej informacji na temat opóźnienia między regionami świadczenia usługi Azure, zobacz Statystyki opóźnienia w sieci platformy Azure.

Koszt

Podczas tworzenia wielu wystąpień zarządzanych SQL w różnych regionach są naliczane opłaty za każde wystąpienie zarządzane SQL.

Jeśli jednak wystąpienie pomocnicze nie ma żadnych obciążeń odczytu ani aplikacji, możesz zaoszczędzić na kosztach licencjonowania, określając replikę jako wystąpienie rezerwowe. Aby uzyskać więcej informacji, zobacz Konfigurowanie repliki rezerwowej bez licencji dla usługi SQL Managed Instance.

Aby uzyskać więcej informacji na temat cennika usługi SQL Managed Instance, zobacz Informacje o cenach usługi.

Konfigurowanie obsługi wielu regionów

Aby dowiedzieć się, jak skonfigurować grupę trybu failover, zobacz Konfigurowanie grupy trybu failover dla usługi SQL Managed Instance.

Planowanie pojemności i zarządzanie nimi

Podczas przechodzenia w tryb failover ruch jest przekierowywany do pomocniczego wystąpienia zarządzanego SQL. Ważne jest, aby pomocnicze wystąpienie zarządzane SQL było gotowe do odbierania ruchu. Utwórz pomocnicze wystąpienie zarządzane SQL z tą samą warstwą usługi, generowaniem sprzętu i rozmiarem obliczeniowym co wystąpienie podstawowe.

Aby uzyskać więcej informacji na temat skalowania wystąpień zarządzanych SQL w grupie przełączania awaryjnego, zobacz Skalowanie wystąpień.

Zachowanie, gdy wszystkie regiony są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać, gdy wystąpienia zarządzane SQL są skonfigurowane do korzystania z grup przełączania awaryjnego w wielu regionach i wszystkie regiony działają.

  • Routing ruchu między regionami: Podczas normalnych operacji żądania odczytu i zapisu przechodzą do pojedynczego wystąpienia podstawowego w regionie podstawowym.

    Grupy trybu failover udostępniają również oddzielny punkt końcowy odbiornika tylko do odczytu. Podczas normalnych operacji ten punkt końcowy łączy się z wystąpieniem pomocniczym w celu kierowania ruchu tylko do odczytu określonego w parametrach połączenia.

    Aby uzyskać więcej informacji na temat sposobu, w jaki grupy przełączeniowe wysyłają ruch do poszczególnych instancji oraz jak można skierować ruch do punktu końcowego odbiornika tylko do odczytu, zobacz Omówienie grup przełączeniowych i najlepsze praktyki.

  • Replikacja danych między regionami: Domyślnie dane są replikowane asynchronicznie z wystąpienia podstawowego do pomocniczego wystąpienia zarządzanego SQL.

    Ponieważ replikacja geograficzna jest asynchroniczna, w przypadku przeprowadzenia wymuszonego przejścia w tryb failover możliwe jest utratę danych. Opóźnienie replikacji można monitorować, aby zrozumieć potencjalną utratę danych podczas wymuszonego przejścia w tryb failover. Aby uzyskać więcej informacji, zobacz Lista kontrolna odzyskiwania po awarii.

    Jeśli musisz wyeliminować utratę danych z replikacji asynchronicznej podczas pracy w trybie failover, skonfiguruj aplikację, aby zablokować wątek wywołujący, dopóki nie potwierdzi, że ostatnia zatwierdzona transakcja została przesłana i wzmocniona w dzienniku transakcji pomocniczej bazy danych. Takie podejście wymaga tworzenia niestandardowego i obniża wydajność aplikacji. Aby uzyskać więcej informacji, zobacz Zapobieganie utracie krytycznych danych.

Zachowanie podczas awarii regionu

W tej sekcji opisano, czego można oczekiwać, gdy zarządzane wystąpienia SQL są skonfigurowane do używania grup failover dla wielu regionów i w regionie podstawowym wystąpi awaria.

  • Wykrywanie i reagowanie: Odpowiedzialność za wykrywanie i reagowanie zależy od polityki failover używanych przez grupę failover.

    • Zasady trybu failover zarządzane przez klienta: Odpowiadasz za wykrywanie awarii w regionie i wyzwalanie trybu failover lub wymuszonego przejścia w tryb failover do wystąpienia pomocniczego w grupie trybu failover.

      W przypadku przełączenia awaryjnego, zarządzana instancja SQL czeka na synchronizację danych z instancją podrzędną przed wykonaniem procedury przełączenia awaryjnego.

      Jeśli wykonasz wymuszone przejście w tryb failover, usługa SQL Managed Instance natychmiast przełączy wystąpienie pomocnicze do roli podstawowej bez oczekiwania na propagację ostatnich zmian z serwera podstawowego. Ten typ trybu failover może spowodować utratę danych.

    • Zasady trybu failover zarządzane przez firmę Microsoft: Tryby failover zarządzane przez firmę Microsoft są wykonywane w wyjątkowych okolicznościach. Gdy firma Microsoft wyzwala tryb failover, grupa trybu failover automatycznie wykonuje wymuszone przejście w tryb failover do wystąpienia pomocniczego w grupie trybu failover. Zalecamy jednak użycie zasad trybu failover zarządzanego przez klienta dla obciążeń produkcyjnych, aby można było kontrolować, kiedy nastąpi przejście w tryb failover.

  • Aktywne żądania: Po przejściu w tryb failover wszystkie przetwarzane żądania są przerywane i muszą zostać ponowione. Aby aplikacje były odporne na te typy problemów, zobacz Odporność na błędy przejściowe.

  • Oczekiwana utrata danych: Ilość utraty danych zależy od sposobu konfigurowania aplikacji. Aby uzyskać więcej informacji, zobacz Omówienie grup trybu failover i najlepsze rozwiązania.

  • Oczekiwany przestój: Podczas przełączenia grupy failover może wystąpić niewielki przestój. Przestój jest zwykle krótszy niż 60 sekund.

  • Przekierowywanie ruchu: Po zakończeniu procesu przełączania przez grupę failover, ruch odczytu i zapisu jest automatycznie kierowany do nowej podstawowej instancji. Jeśli aplikacje używają punktów końcowych grupy trybu failover w parametrach połączenia, nie muszą modyfikować parametrów połączenia po przejściu w tryb failover.

Odzyskiwanie regionów

Grupy trybu failover nie wracają automatycznie po awarii do regionu podstawowego po przywróceniu, dlatego twoim zadaniem jest zainicjowanie powrotu po awarii.

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

Możesz przetestować przełączenie awaryjne grupy.

Testowanie grupy przełączania awaryjnego jest tylko jedną częścią wykonywania próbnej procedury odzyskiwania po awarii. Aby uzyskać więcej informacji, zobacz Przeprowadzanie przerw technicznych.

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 zapasowe nie są takie same jak replikacja geograficzna i mają różne cele i zmniejszają różne zagrożenia.

Wystąpienie zarządzane SQL automatycznie wykonuje pełne, różnicowe i transakcyjne kopie zapasowe twoich baz danych. Aby uzyskać więcej informacji na temat typów kopii zapasowych, ich częstotliwości, możliwości przywracania, kosztów magazynowania i szyfrowania kopii zapasowych, zobacz Automatyczne kopie zapasowe w usłudze SQL Managed Instance.

Usługa SQL Managed Instance udostępnia wbudowane automatyczne kopie zapasowe, a także obsługuje kopie zapasowe tylko do kopiowania inicjowane przez użytkownika dla baz danych użytkowników. Aby uzyskać więcej informacji, zobacz Kopie zapasowe tylko do kopiowania.

Replikacja kopii zapasowej

Podczas konfigurowania automatycznych kopii zapasowych dla wystąpienia zarządzanego SQL można określić sposób replikacji kopii zapasowych. Kopie zapasowe skonfigurowane do przechowywania w usłudze ZRS charakteryzują się wyższym poziomem odporności. Zalecamy skonfigurowanie kopii zapasowych tak, aby korzystały z jednego z następujących typów magazynu:

  • ZRS dla zapewnienia odporności w regionie, jeśli region ma strefy dostępności

  • Magazyn GZRS w celu zwiększenia odporności kopii zapasowych między regionami, jeśli region ma strefy dostępności i jest sparowany z innym regionem

  • GRS, jeśli Twój region nie obsługuje stref dostępności, ale posiada sparowany region.

Aby uzyskać więcej informacji na temat różnych typów magazynu i ich możliwości, zobacz Nadmiarowość magazynu kopii zapasowych.

Przywracanie geograficzne

Funkcja przywracania geograficznego to podstawowe rozwiązanie odzyskiwania po awarii, które umożliwia przywracanie kopii zapasowych do innego regionu świadczenia usługi Azure. Geograficzna kopia zapasowa zwykle wymaga znacznego przestoju i utraty danych. Aby osiągnąć wyższy poziom możliwości odzyskiwania w przypadku wystąpienia regionalnych zakłóceń, należy skonfigurować grupy przełączania awaryjnego.

Jeśli używasz przywracania geograficznego, musisz wziąć pod uwagę sposób udostępniania kopii zapasowych w regionie pomocniczym:

Odporność usługi na prace konserwacyjne

Gdy wystąpienie zarządzane SQL wykonuje konserwację wystąpienia, wystąpienie zarządzane SQL pozostaje w pełni dostępne, ale może podlegać krótkiej rekonfiguracji. Aplikacje klienckie mogą obserwować krótkie przerwy w łączności w przypadku wystąpienia zdarzenia konserwacji. Aplikacje klienckie powinny postępować zgodnie ze wskazówkami dotyczącymi odporności na błędy przejściowe , aby zminimalizować skutki.

Usługa SQL Managed Instance 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 przechodzenie w tryb failover, w godzinach pracy. Możesz również otrzymywać powiadomienia z wyprzedzeniem o planowanej konserwacji.

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

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.

W przypadku usługi SQL Managed Instance umowa SLA dotycząca dostępności ma zastosowanie tylko wtedy, gdy sieć wirtualna platformy Azure jest poprawnie skonfigurowana, tak aby nie utrudniała ruchu związanego z zarządzaniem. Ta konfiguracja obejmuje rozmiar podsieci, sieciowe grupy zabezpieczeń, trasy zdefiniowane przez użytkownika (UDR), konfigurację DNS i inne zasoby wpływające na zarządzanie zasobami sieciowymi i korzystanie z nich. Aby uzyskać więcej informacji na temat wymaganej konfiguracji sieci dla usługi SQL Managed Instance, zobacz Wymagania dotyczące sieci.

Treści powiązane

  • Last updated on