Dela via

Användarinitierad manuell redundansväxling på SQL Managed Instance

  • Artikel

Gäller för:Azure SQL Managed Instance

Den här artikeln beskriver hur du manuellt redundansväxlar en primär nod på TJÄNSTnivåer för SQL Managed Instance General Purpose (GP) och Affärskritisk (BC) och hur du manuellt redundansväxlar en sekundär skrivskyddad repliknod endast på BC-tjänstnivån.

Kommentar

Den här artikeln är inte relaterad till redundans mellan regioner med redundansgrupper.

När du ska använda manuell redundans

Hög tillgänglighet är en grundläggande del av SQL Managed Instance-plattformen som fungerar transparent för dina databasprogram. Redundansväxlingar från primära till sekundära noder när nodernas prestanda försämras eller identifierar fel, eller vid regelbundna månatliga programuppdateringar, är något som förväntas för alla program som använder SQL Managed Instance i Azure.

Du kan överväga att köra en manuell redundansväxling på SQL Managed Instance av följande orsaker:

  • Testa program för redundansåterhämtning innan du distribuerar till produktionen
  • Testa system för felåterhämtning från slutpunkt till slutpunkt med automatisk redundans
  • Testa hur redundans påverkar dina befintliga databassessioner
  • Kontrollera om en redundans ändrar den övergripande prestandan på grund av ändringar i nätverksfördröjningen
  • I vissa fall kan manuell redundans hjälpa till att minska problem med prestanda när frågeprestandan försämras.

Kommentar

Att se till att dina program är redundanståliga innan de distribueras till produktion bidrar till att minska risken för programfel i produktionen och bidrar till programtillgängligheten för dina kunder. Läs mer om att testa dina program för molnberedskap med testappens molnberedskap för redundansåterhämtning med SQL Managed Instance-videoinspelning .

Initiera manuell redundansväxling på SQL Managed Instance

Azure RBAC-behörigheter krävs

Användare som initierar en redundansväxling måste ha någon av följande Azure-roller:

  • Rollen Prenumerationsägare eller
  • Sql Managed Instance-deltagarroll , eller
  • Anpassad roll med följande behörighet:
    • Microsoft.Sql/managedInstances/failover/action

Använda PowerShell

Den lägsta versionen av Az.Sql måste vara v2.9.0. Överväg att använda Azure Cloud Shell från Azure-portalen som alltid har den senaste Tillgängliga PowerShell-versionen.

Som ett förhandskrav använder du följande PowerShell-skript för att installera nödvändiga Azure-moduler. Välj dessutom den prenumeration där SQL Managed Instance som du vill redundansväxlar finns.

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

Connect-AzAccount
Select-AzSubscription -SubscriptionId $subscription

Använd PowerShell-kommandot Invoke-AzSqlInstanceFailover med följande exempel för att initiera redundans för den primära noden, som gäller för både BC- och GP-tjänstnivån.

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

Använd följande PowerShell-kommando för att redundansläsa den sekundära noden, som endast gäller för BC-tjänstnivå.

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

Använda CLI

Se till att de senaste CLI-skripten är installerade.

Använd cli-kommandot az sql mi failover med följande exempel för att initiera redundans för den primära noden, som gäller för både BC- och GP-tjänstnivån.

az sql mi failover -g myresourcegroup -n myinstancename

Använd följande CLI-kommando för att redundansläsa den sekundära noden, som endast gäller för BC-tjänstnivån.

az sql mi failover -g myresourcegroup -n myinstancename --replica-type ReadableSecondary

Använda REST-API

För avancerade användare som kanske skulle behöva automatisera redundansväxlingar av sina SQL Managed Instances i syfte att implementera pipeline för kontinuerlig testning eller automatiserade prestandamigatorer kan den här funktionen utföras genom att initiera redundans via ett API-anrop. Mer information finns i SQL Managed Instances – REST API för redundans.

Om du vill initiera redundansväxling med hjälp av REST API-anrop genererar du först den Auth-token med hjälp av valfri API-klient. Den genererade autentiseringstoken används som auktoriseringsegenskap i rubriken för API-begäran och är obligatorisk.

Följande kod är ett exempel på API-URI:n som ska anropas:

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Sql/managedInstances/{managedInstanceName}/failover?api-version=2019-06-01-preview

Följande egenskaper måste skickas i API-anropet:

API-egenskap Parameter
subscriptionId Prenumerations-ID som den hanterade instansen distribueras till
resourceGroupName Resursgrupp som innehåller hanterad instans
managedInstanceName Namn på hanterad instans
replicaType (Valfritt) (Primär eller LäsbarSekondary). Dessa parametrar representerar den typ av replik som ska växlas över: primär eller läsbar sekundär. Om det inte anges initieras redundans på den primära repliken som standard.
api-version Statiskt värde och måste för närvarande vara "2019-06-01-preview"

API svarar med något av följande två:

  • 202 Accepterad
  • Ett av 400-begärandefelen.

Åtgärdsstatus kan spåras genom att granska API-svar i svarshuvuden. Mer information finns i Status för asynkrona Azure-åtgärder.

Övervaka redundansväxlingen

Om du vill övervaka förloppet för användarinitierad redundans för din BC-instans kör du följande T-SQL-fråga i din favoritklient (till exempel SSMS) på SQL Managed Instance. Den läser systemvyn sys.dm_hadr_fabric_replica_states och rapportrepliker som är tillgängliga på instansen. Uppdatera samma fråga när du har initierat den manuella redundansväxlingen.

SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states

Innan du påbörjar redundansväxlingen anger dina utdata den aktuella primära repliken på BC-tjänstnivån som innehåller en primär och tre sekundärfiler i AlwaysOn-tillgänglighetsgruppen. Vid körning av en redundansväxling måste den här frågan köras igen för att indikera en ändring av den primära noden.

Du kommer inte att kunna se samma utdata med GP-tjänstnivån som den ovan som visas för BC. Det beror på att GP-tjänstnivån endast baseras på en enda nod. Du kan använda en alternativ T-SQL-fråga som visar när SQL-processen startades på noden för GP-tjänstnivåinstansen:

SELECT sqlserver_start_time, sqlserver_start_time_ms_ticks FROM sys.dm_os_sys_info

Den korta förlusten av anslutning från klienten under redundansväxlingen, som vanligtvis varar under en minut, är indikationen på redundanskörningen oavsett tjänstnivå.

Kommentar

Slutförandet av redundansväxlingsprocessen (inte den faktiska korta otillgängligheten) kan ta flera minuter i taget vid högintensiva arbetsbelastningar. Det beror på att instansmotorn tar hand om alla aktuella transaktioner på den primära och kommer ikapp den sekundära noden innan den kan redundans.

Viktigt!

Funktionella begränsningar för användarinitierad manuell redundans är:

  • En (1) redundansväxling kan initieras på samma SQL Managed Instance var 15:e minut.
  • För BC-instanser måste det finnas kvorum av repliker för att redundansbegäran ska accepteras.
  • För BC-instanser går det inte att ange vilken läsbar sekundär replik som ska initiera redundansväxlingen.
  • Redundans tillåts inte förrän den första fullständiga säkerhetskopieringen för en ny databas har slutförts av automatiserade säkerhetskopieringssystem.
  • Redundans tillåts inte om det finns en pågående databasåterställning.

Nästa steg