Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
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:
- Rola właściciela subskrypcji lub
- Rola współautora na platformie SQL Managed Instance lub
- Rola niestandardowa z następującymi uprawnieniami:
Microsoft.Sql/managedInstances/failover/action
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_states
aby 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.
Powiązana zawartość
- Dowiedz się więcej o testowaniu swoich aplikacji pod kątem gotowości chmurowej i odporności w trybie failover z nagraniem wideo Testowanie gotowości aplikacji do chmury z wykorzystaniem usługi SQL Managed Instance.
- Dowiedz się więcej o wysokiej dostępności usługi Azure SQL Managed Instance Wysoka dostępność dla zarządzanego wystąpienia Azure SQL.
- Aby zapoznać się z omówieniem, zobacz Co to jest usługa Azure SQL Managed Instance?.