Sdílet prostřednictvím

Restartování instance s ručním převzetím služeb při selhání iniciované uživatelem – Azure SQL Managed Instance

  • Článek

Platí pro: Azure SQL Managed Instance

Tento článek vysvětluje, jak restartovat službu Azure SQL Managed Instance provedením ručního převzetí služeb při selhání iniciovaného uživatelem do sekundárního výpočetního uzlu pomocí PowerShellu, Azure CLI nebo rozhraní REST API.

Převzetí služeb při selhání primárního uzlu ve vrstvě služby BC (General Purpose) a Pro důležité obchodní informace (BC) a ruční převzetí služeb při selhání sekundárního uzlu repliky jen pro čtení ve vrstvě služby BC.

Poznámka:

Převzetí služeb při selhání v tomto článku se týká spuštění procesu databázového stroje SQL Serveru na sekundárním uzlu a nesouvisí s převzetím služeb při selhání skupin převzetí služeb při selhání mezi oblastmi.

Kdy použít ruční převzetí služeb při selhání

Dostupnost, základní část platformy SQL Managed Instance, funguje transparentně pro databázové aplikace tím, že poskytuje místní pohotovostní výpočetní uzly pro hostování procesu databázového stroje SQL Serveru. Převzetí služeb při selhání nastane, když se proces databázového stroje SQL Serveru přenese do offline režimu na primárním výpočetním uzlu a přenese se do režimu online na sekundárním výpočetním uzlu. Převzetí služeb při selhání mezi výpočetními uzly spravované instance SQL jsou obvykle automatické a spravované platformou při zjištění chyby, snížení výkonu uzlu nebo při pravidelných měsíčních aktualizacích softwaru.

Celá operace převzetí služeb při selhání se skládá z online procesu databázového stroje SQL Serveru na sekundárním uzlu, ověření stavu databáze a následného přesměrování připojení klienta k novému primárnímu uzlu. Připojení klientů selhávají jenom po krátkou dobu, obvykle pod minutou během posledního kroku operace převzetí služeb při selhání.

Ruční převzetí služeb při selhání můžete spustit, aby se proces motoru restartoval na jiném uzlu z následujících důvodů:

  • Neúspěšná přihlášení nebo zpomalení kvůli problémům s výkonem
  • Testování aplikace pro zajištění odolnosti při selhání před nasazením do produkčního prostředí
  • Testování komplexních systémů pro odolnost proti chybám při automatickém převzetí služeb při selhání
  • Testování dopadu převzetí služeb při selhání na existující databázové relace
  • Snížení výkonu dotazů (restartování instance může pomoct zmírnit problém s výkonem).

Zajištění odolnosti vašich aplikací před nasazením do produkčního prostředí pomáhá zmírnit riziko chyb aplikací v produkčním prostředí a přispět k dostupnosti aplikací pro vaše zákazníky. Další informace o testování aplikací pro připravenost cloudu najdete v následujícím videu:

Následující tabulka popisuje očekávané chování spravované instance SQL během operace převzetí služeb při selhání na základě úrovně služby a modelu dostupnosti:

Úroveň služby Model dostupnosti Očekávané chování převzetí služeb při selhání Potenciální chování při selhání (výjimky)
Pro obecné účely Místní redundance
(Jedna zóna dostupnosti)		 Proces SQL se restartuje na stejném virtuálním počítači. Proces SQL se restartuje na jiném virtuálním počítači.
Pro obecné účely Redundance zón (Preview)
(Více zón dostupnosti)		 Proces SQL se restartuje na stejném virtuálním počítači. Proces SQL se restartuje na jiném virtuálním počítači.
Pro důležité obchodní informace Místní redundance
(Jedna zóna dostupnosti)		 Náhodná sekundární replika se upřednostní na primární. –
Pro důležité obchodní informace Redundance zón
(Více zón dostupnosti)		 Random secondary replica is promoted to primary, either in the same or different availability zone. –

Oprávnění

Uživatelé, kteří iniciují převzetí služeb při selhání, musí mít jednu z následujících rolí Azure:

  • Role vlastníka předplatného, nebo
  • Role Přispěvatel spravované instance SQL nebo
  • Vlastní role s následujícími oprávněními:
    • Microsoft.Sql/managedInstances/failover/action

Restartování instance s ručním převzetím služeb při selhání

Instanci můžete restartovat s ručním převzetím služeb při selhání pomocí PowerShellu, Azure CLI nebo rozhraní REST API.

Minimální verze Az.Sql musí být v2.9.0. Zvažte použití Azure Cloud Shellu z webu Azure Portal, která má vždy k dispozici nejnovější verzi PowerShellu.

Jako předběžný požadavek použijte následující skript PowerShellu k instalaci požadovaných modulů Azure. Kromě toho vyberte předplatné, ve kterém se nachází spravovaná instance SQL, kterou chcete provést převzetí služeb při selhání.

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

Connect-AzAccount
Select-AzSubscription -SubscriptionId $subscription

Pomocí příkazu PowerShell Invoke-AzSqlInstanceFailover s následujícím příkladem zahajte převzetí služeb při selhání primárního uzlu, které platí pro úroveň služby BC i GP.

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

K převzetí služeb při selhání sekundárního uzlu čtení použijte následující příkaz PowerShellu, který se vztahuje pouze na úroveň služby BC.

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

Monitorování převzetí služeb při selhání

Monitorování průběhu převzetí služeb při selhání iniciovaného uživatelem se liší u instancí v úrovních služby Pro důležité obchodní informace a Pro obecné účely.

Pokud chcete monitorovat průběh převzetí služeb při selhání iniciovaného uživatelem, použijte:

  • sys.dm_os_sys_info zkontrolujte dobu provozu systému pro úroveň služby Pro obecné účely.
  • sys.dm_hadr_fabric_replica_statesa zkontrolujte dostupné repliky pro úroveň služby Pro důležité obchodní informace.

Posledním krokem procesu převzetí služeb při selhání je přesměrování připojení klientů k novému primárnímu uzlu. Krátká ztráta připojení z vašeho klienta během převzetí služeb při selhání, obvykle trvající méně než minutu, značí, že převzetí služeb při selhání proběhlo úspěšně – bez ohledu na úroveň služby.

Úroveň služby pro obecné účely

Následující příklad T-SQL ukazuje dobu provozu procesu SQL na uzlu pro úroveň služby Pro obecné účely :

SELECT sqlserver_start_time, sqlserver_start_time_ms_ticks FROM sys.dm_os_sys_info

Čas spuštění procesu SQL je čas spuštění procesu databázového stroje SQL Serveru v uzlu. Čas se restartuje po dokončení převzetí služeb při selhání. Spusťte tento dotaz před zahájením převzetí služeb při selhání instance na úrovni služby Pro obecné účely a sledujte průběh operace převzetí služeb při selhání.

úroveň služby Pro důležité obchodní informace

Následující příklad T-SQL označuje, který uzel je aktuálně primární replikou pro úroveň služby Pro důležité obchodní informace:

SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states

Uzel, který je hostitelem primární repliky, se po dokončení převzetí služeb při selhání změní. Spusťte tento dotaz před zahájením převzetí služeb při selhání instance ve vrstvě služby Pro důležité obchodní informace a po ní, abyste mohli monitorovat průběh operace převzetí služeb při selhání.

Poznámka:

Dokončení celého procesu převzetí služeb při selhání může trvat několik minut během úloh s vysokou intenzitou , protože modul instancí zajišťuje, že transakce na sekundárním uzlu se před zahájením převzetí služeb při selhání zachytí do transakcí z primárního uzlu.

Omezení

Zvažte následující funkční omezení ručního převzetí služeb při selhání iniciované uživatelem:

  • Ve stejné instanci SQL Managed Instance může být zahájeno pouze jedno převzetí služeb při selhání (1) každých 15 minut.
  • Převzetí služeb při selhání není povolené:
    • Až do dokončení prvního úplného zálohování nové databáze automatizovanými systémy zálohování.
    • pokud probíhá obnovení databáze.
  • Například instance na úrovni služby Pro důležité obchodní informace:
    • Aby bylo možné přijmout žádost o převzetí služeb při selhání, musí existovat kvorum replik replik.
    • Není možné určit, pro kterou repliku čitelnou sekundární repliku se má zahájit převzetí služeb při selhání.

Související obsah