Udostępnij za pośrednictwem


Ponowne uruchamianie wystąpienia przy użyciu ręcznego przejścia w tryb failover zainicjowanego przez użytkownika — Azure SQL Managed Instance

Dotyczy:Azure SQL Managed Instance

W tym artykule wyjaśniono, jak ponownie uruchomić usługę Azure SQL Managed Instance , wykonując ręczne przejście w tryb failover zainicjowane przez użytkownika przy użyciu programu PowerShell, interfejsu wiersza polecenia platformy Azure lub interfejsu API REST.

Istnieje możliwość przejścia w tryb failover węzła podstawowego w warstwach usługi Ogólnego przeznaczenia (GP) i Krytyczne dla działania firmy (BC) oraz ręczne przełączenie w tryb failover pomocniczego węzła repliki tylko do odczytu w warstwie usługi BC.

Uwaga

Przełączenie awaryjne w tym artykule dotyczy ponownego uruchamiania procesu silnika bazy danych SQL Server i nie jest związane z przełączaniem awaryjnym między regionami grup przełączeń awaryjnych.

Kiedy należy użyć ręcznego przełączenia awaryjnego

Dostępność, podstawowy element platformy SQL Managed Instance, działa bezproblemowo dla aplikacji baz danych, zapewniając lokalne węzły obliczeniowe rezerwowe do uruchamiania procesu silnika bazy danych programu SQL Server. Przełączenie awaryjne (failover) następuje, gdy proces aparatu bazy danych SQL Server zostaje wyłączony i następnie włączony na tym samym lub innym węźle obliczeniowym. Zazwyczaj tryby failover są automatyczne i zarządzane przez platformę Azure po wykryciu błędu, obniżonej wydajności węzła lub podczas aktualizacji usługi.

Cała operacja trybu failover polega na uruchomieniu procesu silnika bazy danych SQL Server, zweryfikowaniu stanu bazy danych, a następnie przekierowaniu połączeń klienta do nowego silnika baz danych SQL. Połączenia klienta kończą się niepowodzeniem tylko przez krótki czas, zazwyczaj poniżej minuty, podczas ostatniego etapu przełączania awaryjnego.

Możesz wykonać ręczne przełączenie awaryjne w celu ponownego uruchomienia procesu aparatu z następujących powodów:

  • Nieudane logowania lub spowolnienie z powodu problemów z wydajnością.
  • Testowanie aplikacji pod kątem odporności na awarie przed wdrożeniem w środowisku produkcyjnym.
  • Testowanie kompleksowych systemów pod kątem odporności na awarie podczas automatycznych przełączeń.
  • Testowanie wpływu trybu failover na istniejące sesje bazy danych.
  • Obniżenie wydajności zapytań (ponowne uruchomienie wystąpienia może pomóc rozwiązać problem z wydajnością).

Zapewnienie odporności aplikacji na tryb failover przed wdrożeniem w środowisku produkcyjnym pomaga ograniczyć ryzyko błędów aplikacji w środowisku produkcyjnym i przyczynia się do dostępności aplikacji dla klientów. Dowiedz się więcej na temat testowania aplikacji pod kątem gotowości do chmury, wykonując następujące wideo:

W poniższej tabeli opisano oczekiwane zachowanie zarządzanej instancji SQL podczas operacji failover na podstawie warstwy usługi i modelu dostępności:

Poziom usługi Model dostępności Oczekiwane zachowanie trybu failover Potencjalne zachowanie awaryjnego przełączania (wyjątki)
Ogólnego przeznaczenia Nadmiarowość lokalna
(Pojedyncza strefa dostępności)
Proces SQL jest uruchamiany ponownie na tej samej maszynie wirtualnej. Proces SQL jest uruchamiany ponownie na innej maszynie wirtualnej.
Ogólnego przeznaczenia Nadmiarowość strefy
(Wiele stref dostępności)
Proces SQL jest uruchamiany ponownie na tej samej maszynie wirtualnej. Proces SQL jest uruchamiany ponownie na innej maszynie wirtualnej.
Krytyczne dla działania firmy Nadmiarowość lokalna
(Pojedyncza strefa dostępności)
Proces SQL jest uruchamiany ponownie w replice podstawowej lub replika pomocnicza losowa jest promowana do podstawowej. Nie dotyczy
Krytyczne dla działania firmy Nadmiarowość strefy
(Wiele stref dostępności)
Proces SQL jest uruchamiany ponownie w replice podstawowej lub replika pomocnicza losowa jest promowana do podstawowej lub innej strefy dostępności. Nie dotyczy

Uprawnienia

Użytkownicy inicjujący tryb failover muszą mieć jedną z następujących ról platformy Azure:

Zrestartuj wystąpienie za pomocą ręcznego failover

Wystąpienie można ponownie uruchomić przy użyciu ręcznego przejścia w tryb failover przy użyciu programu PowerShell, interfejsu wiersza polecenia platformy Azure lub interfejsu API REST.

Minimalna wersja modułu Az.Sql musi być w wersji 2.9.0. Rozważ użycie usługi Azure Cloud Shell w witrynie Azure Portal, która zawsze ma najnowszą dostępną wersję programu PowerShell.

Aby zainstalować wymagane moduły platformy Azure, użyj następującego skryptu programu PowerShell. Ponadto wybierz subskrypcję, w której znajduje się zarządzane wystąpienie SQL, na którym chcesz przeprowadzić tryb failover.

$subscription = 'enter your subscription ID here'
Install-Module -Name Az
Import-Module Az.Accounts
Import-Module Az.Sql

Connect-AzAccount
Select-AzSubscription -SubscriptionId $subscription

Użyj polecenia programu PowerShell Invoke-AzSqlInstanceFailover z poniższym przykładem, aby zainicjować tryb failover węzła podstawowego, który ma zastosowanie zarówno do warstwy usługi BC, jak i GP.

$ResourceGroup = 'enter resource group of your MI'
$ManagedInstanceName = 'enter MI name'
Invoke-AzSqlInstanceFailover -ResourceGroupName $ResourceGroup -Name $ManagedInstanceName

Użyj następującego polecenia programu PowerShell, aby przejść w tryb failover do odczytu pomocniczego węzła, który ma zastosowanie tylko do warstwy usług BC.

$ResourceGroup = 'enter resource group of your MI'
$ManagedInstanceName = 'enter MI name'
Invoke-AzSqlInstanceFailover -ResourceGroupName $ResourceGroup -Name $ManagedInstanceName -ReadableSecondary

Monitorowanie trybu failover

Monitorowanie postępu failover zainicjowanego przez użytkownika różni się w przypadku instancji w warstwach usług Business Critical i General Purpose.

Aby monitorować postęp zainicjowanego przez użytkownika przełączenia awaryjnego, użyj:

  • Aby sprawdzić czas pracy systemu dla warstwy usługi Ogólnego Przeznaczenia, użyj sys.dm_os_sys_info.
  • sys.dm_hadr_fabric_replica_statesaby sprawdzić dostępne repliki dla warstwy usługi Krytyczne dla działania firmy.

Ostatnim krokiem procesu pracy w trybie failover jest przekierowanie połączeń klienta do nowego węzła podstawowego. Krótka utrata łączności z klientem podczas pracy w trybie failover, zazwyczaj trwa poniżej minuty, wskazuje, że przejście w tryb failover zakończyło się pomyślnie — niezależnie od warstwy usługi.

Warstwa usługi Ogólnego przeznaczenia

Poniższy przykład języka T-SQL przedstawia czas działania procesu SQL w węźle dla warstwy usługi Ogólnego przeznaczenia :

SELECT sqlserver_start_time, sqlserver_start_time_ms_ticks FROM sys.dm_os_sys_info

Czas uruchomienia procesu SQL to czas rozpoczęcia procesu aparatu bazy danych programu SQL Server na węźle, który jest aktualizowany po każdym failoverze. Uruchom to zapytanie przed i po zainicjowaniu trybu failover wystąpienia w warstwie usługi Ogólnego przeznaczenia, aby monitorować postęp operacji trybu failover.

warstwa usługi biznesowej o znaczeniu krytycznym

Poniższy przykład T-SQL wskazuje, który węzeł jest obecnie repliką podstawową dla usługi krytycznej dla biznesu:

SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states

Węzeł hostujący replikę podstawową zmienia się po zakończeniu procesu failover. Uruchom to zapytanie przed i po zainicjowaniu przełączenia awaryjnego wystąpienia w warstwie usługi o kluczowym znaczeniu dla biznesu, aby monitorować postęp operacji przełączenia awaryjnego.

Uwaga

Pełny proces przełączenia awaryjnego może potrwać kilka minut podczas obciążeń o wysokiej intensywności, ponieważ silnik instancji zapewnia, że transakcje w węźle pomocniczym są wyrównywane z transakcjami na węźle podstawowym przed zainicjowaniem przełączenia awaryjnego.

Ograniczenia

Rozważ następujące ograniczenia funkcjonalne ręcznego failoveru inicjowanego przez użytkownika:

  • Na tym samym wystąpieniu zarządzanym SQL może być zainicjowane tylko jedno (1) przełączenie awaryjne co 15 minut.
  • Procedury awaryjne nie są dozwolone:
    • Do momentu ukończenia pierwszej pełnej kopii zapasowej nowej bazy danych przez zautomatyzowane systemy kopii zapasowych.
    • jeśli trwa przywracanie bazy danych.
  • Na przykład w warstwie usługi Krytyczne dla działania firmy:
    • Repliki muszą mieć kworum przed zaakceptowaniem żądania przełączenia awaryjnego.
    • Polecenie Invoke-AzSqlInstanceFailover powoduje przełączenie repliki podstawowej w tryb failover, chyba że zostanie określone -ReadableSecondary, w takim przypadku przełączenie w tryb failover dotyczy repliki pomocniczej z możliwością odczytu. Repliki pomocnicze nie do odczytu nie są w trybie failover po wydaniu tego polecenia.