User-initiated manual failover on SQL Managed Instance (Door gebruiker geïnitieerde handmatige failover op een SQL Managed Instance)

Van toepassing op: Azure SQL Managed Instance

In dit artikel wordt uitgelegd hoe u handmatig een failover uitvoert van een primair knooppunt in de servicelagen Algemeen gebruik (GP) van SQL Managed Instance en Bedrijfskritiek (BC) en hoe u handmatig een failover uitvoert voor een secundair alleen-lezen replicaknooppunt in de BC-servicelaag.

Notitie

Dit artikel heeft geen betrekking op failovers tussen regio's met failovergroepen.

Wanneer moet u handmatige failover gebruiken

Hoge beschikbaarheid is een fundamenteel onderdeel van het SQL Managed Instance-platform dat transparant werkt voor uw databasetoepassingen. Failovers van primaire naar secundaire knooppunten in het geval van knooppuntdegradatie of foutdetectie, of tijdens regelmatige maandelijkse software-updates is een verwachte gebeurtenis voor alle toepassingen die SQL Managed Instance in Azure gebruiken.

U kunt overwegen om een handmatige failover uit te voeren op SQL Managed Instance om een aantal van de volgende redenen:

  • Testtoepassing voor failovertolerantie voordat die in productie wordt geïmplementeerd
  • End-to-endsystemen testen voor de fouttolerantie bij automatische failovers
  • Test hoe failover van invloed is op bestaande databasesessies
  • Controleer of een failover de end-to-end-prestaties wijzigt vanwege eventuele wijzigingen in de netwerklatentie
  • In sommige gevallen van prestatievermindering van query's kan een handmatige failover helpen het prestatieprobleem te verhelpen.

Notitie

Ervoor zorgen dat uw toepassingen failoverbestendig zijn voordat ze in productie worden geïmplementeerd, helpt het risico op toepassingsfouten in productie te beperken en bij te dragen aan de beschikbaarheid van toepassingen voor uw klanten. Meer informatie over het testen van uw toepassingen voor cloudgereedheid met app-cloudgereedheid testen voor failovertolerantie met video-opname van SQL Managed Instance .

Handmatige failover initiëren in SQL Managed Instance

Vereiste Azure RBAC-machtigingen

Gebruikers die een failover starten, moeten een van de volgende Azure-rollen hebben:

  • Rol van abonnementseigenaar, of
  • Rol inzender voor SQL Managed Instance, of
  • Aangepaste rol met de volgende machtiging:
    • Microsoft.Sql/managedInstances/failover/action

PowerShell gebruiken

De minimale versie van Az.Sql moet v2.9.0 zijn. Overweeg om Azure Cloud Shell te gebruiken vanuit De Azure-portal die altijd de nieuwste PowerShell-versie beschikbaar heeft.

Gebruik als vereiste het volgende PowerShell-script om de vereiste Azure-modules te installeren. Selecteer bovendien het abonnement waarin sql Managed Instance zich bevindt waar u een failover wilt uitvoeren.

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

Connect-AzAccount
Select-AzSubscription -SubscriptionId $subscription

Gebruik de PowerShell-opdracht Invoke-AzSqlInstanceFailover met het volgende voorbeeld om failover van het primaire knooppunt te initiëren, dat van toepassing is op de servicelaag BC en GP.

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

Gebruik de volgende PowerShell-opdracht om een failover uit te voeren voor secundair knooppunt, dat alleen van toepassing is op de BC-servicelaag.

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

CLI gebruiken

Zorg ervoor dat de meest recente CLI-scripts zijn geïnstalleerd.

Gebruik de CLI-opdracht az sql mi failover met het volgende voorbeeld om een failover van het primaire knooppunt te initiëren, dat van toepassing is op de servicelaag BC en GP.

az sql mi failover -g myresourcegroup -n myinstancename

Gebruik de volgende CLI-opdracht om een failover uit te voeren voor secundair knooppunt, dat alleen van toepassing is op de BC-servicelaag.

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

REST API gebruiken

Voor geavanceerde gebruikers die mogelijk failovers van hun SQL Managed Instances moeten automatiseren voor het implementeren van een pijplijn voor continue tests of geautomatiseerde prestatie-mitigators, kan deze functie worden uitgevoerd via het initiëren van failover via een API-aanroep. Zie SQL Managed Instances - Failover REST API voor meer informatie.

Als u een failover wilt initiëren met behulp van een REST API-aanroep, genereert u eerst het verificatietoken met behulp van de API-client van uw keuze. Het gegenereerde verificatietoken wordt gebruikt als autorisatie-eigenschap in de header van de API-aanvraag en is verplicht.

De volgende code is een voorbeeld van de API-URI die moet worden aangeroepen:

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

De volgende eigenschappen moeten worden doorgegeven in de API-aanroep:

API-eigenschap Parameter
subscriptionId Abonnements-id waarop het beheerde exemplaar wordt geïmplementeerd
resourceGroupName Resourcegroep die een beheerd exemplaar bevat
managedInstanceName Naam van beheerd exemplaar
replicaType (Optioneel) (Primaire of LeesbareSecondary). Deze parameters vertegenwoordigen het type replica waarvoor een failover moet worden uitgevoerd: primaire of leesbare secundaire. Als deze niet is opgegeven, wordt failover standaard gestart op de primaire replica.
api-versie Statische waarde en moet momenteel '2019-06-01-preview' zijn

API reageert met een van de volgende twee:

  • 202 Geaccepteerd
  • Een van de 400 aanvraagfouten.

De bewerkingsstatus kan worden bijgehouden door API-antwoorden in antwoordheaders te controleren. Zie De status van asynchrone Azure-bewerkingen voor meer informatie.

De failover bewaken

Als u de voortgang van door de gebruiker geïnitieerde failover voor uw BC-exemplaar wilt controleren, voert u de volgende T-SQL-query uit in uw favoriete client (bijvoorbeeld SSMS) in SQL Managed Instance. Het leest de systeemweergave sys.dm_hadr_fabric_replica_states en rapportreplica's die beschikbaar zijn voor het exemplaar. Vernieuw dezelfde query nadat u de handmatige failover hebt gestart.

SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states

Voordat u de failover start, geeft uw uitvoer de huidige primaire replica op de BC-servicelaag aan met één primaire en drie secundaire databases in de AlwaysOn-beschikbaarheidsgroep. Bij het uitvoeren van een failover moet deze query opnieuw worden uitgevoerd om een wijziging van het primaire knooppunt aan te geven.

U kunt niet dezelfde uitvoer zien als de GP-servicelaag die hierboven wordt weergegeven voor BC. Dit komt doordat de GP-servicelaag alleen is gebaseerd op één knooppunt. U kunt een alternatieve T-SQL-query gebruiken met het tijdstip waarop het SQL-proces is gestart op het knooppunt voor exemplaar van de GP-servicelaag:

SELECT sqlserver_start_time, sqlserver_start_time_ms_ticks FROM sys.dm_os_sys_info

Het korte verlies van connectiviteit van uw client tijdens de failover, meestal minder dan een minuut, is de indicatie van de failover-uitvoering, ongeacht de servicelaag.

Notitie

Het voltooien van het failoverproces (niet de werkelijke korte onbeschikbaarheid) kan enkele minuten tegelijk duren in het geval van workloads met een hoge intensiteit . Dit komt doordat de instantie-engine alle huidige transacties op het primaire en inhaalt op het secundaire knooppunt voordat de failover kan worden uitgevoerd.

Belangrijk

Functionele beperkingen van door de gebruiker geïnitieerde handmatige failover zijn:

  • Er kan elke 15 minuten één (1) failover worden geïnitieerd op hetzelfde met SQL Managed Instance.
  • Voor BC-exemplaren moet er een quorum van replica's bestaan om de failover-aanvraag te kunnen accepteren.
  • Voor BC-exemplaren is het niet mogelijk om op te geven op welke leesbare secundaire replica de failover moet worden gestart.
  • Failover wordt pas toegestaan als de eerste volledige back-up voor een nieuwe database is voltooid door geautomatiseerde back-upsystemen.
  • Failover is niet toegestaan als er een databaseherstel wordt uitgevoerd.

Volgende stappen