Een exemplaar opnieuw opstarten met een door de gebruiker geïnitieerde handmatige failover - Azure SQL Managed Instance

van toepassing op:Azure SQL Managed Instance

In dit artikel wordt uitgelegd hoe u Azure SQL Managed Instance opnieuw start door een handmatig door de gebruiker geïnitieerde failover uit te voeren met behulp van PowerShell, de Azure CLI of REST API.

Het is mogelijk om een failover uit te voeren van een primair knooppunt in de servicelagen Algemeen gebruik (GP) en Bc (Bedrijfskritiek) en om handmatig een failover uit te voeren van een secundair replicaknooppunt met het kenmerk Alleen-lezen in de BC-servicelaag.

Opmerking

Failover in dit artikel verwijst naar het opnieuw opstarten van het SQL Server-database-engineproces en is niet gerelateerd aan de failover tussen regio's van een failovergroep.

Wanneer moet u handmatige failover gebruiken

Beschikbaarheid, een fundamenteel onderdeel van het SQL Managed Instance-platform, werkt transparant voor uw databasetoepassingen door lokale stand-by-rekenknooppunten te bieden voor het hosten van het SQL Server-database-engineproces. Er treedt een failover op wanneer het SQL Server-database-engineproces offline wordt gehaald en online wordt gebracht op hetzelfde of een ander rekenknooppunt. Failovers worden doorgaans automatisch en beheerd door het Azure-platform wanneer een fout wordt gedetecteerd, een knooppunt is gedegradeerd of tijdens service-updates.

De volledige failoverbewerking bestaat uit het online brengen van het SQL Server-database-engineproces, het valideren van de databasestatus en vervolgens het omleiden van de clientverbindingen naar het nieuwe SQL-proces. Clientverbindingen mislukken slechts gedurende een korte periode, meestal minder dan een minuut, tijdens de laatste stap van de failoverbewerking.

U kunt een handmatige failover uitvoeren om het engineproces opnieuw op te starten om de volgende redenen:

Mislukte aanmeldingen of traagheid vanwege prestatieproblemen.
Test de toepassing voor failovertolerantie voordat deze in productie wordt geïmplementeerd.
End-to-end-systemen testen op fouttolerantie bij automatische failovers.
Testen hoe failover van invloed is op bestaande databasesessies.
Prestatievermindering van query's (het opnieuw opstarten van het exemplaar kan helpen bij het oplossen van het prestatieprobleem).

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 de volgende video:

In de volgende tabel wordt het verwachte gedrag van het beheerde SQL-exemplaar beschreven tijdens een failoverbewerking op basis van de servicelaag en het beschikbaarheidsmodel:

Serviceniveau	Beschikbaarheidsmodel	Verwacht failover-gedrag	Mogelijk failovergedrag (uitzonderingen)
Algemeen gebruik	Lokale redundantie (Enkele beschikbaarheidszone)	Het SQL-proces wordt opnieuw opgestart op dezelfde VIRTUELE machine.	Het SQL-proces wordt opnieuw opgestart op een andere VIRTUELE machine.
Algemeen gebruik	Zone-redundantie (Meerdere beschikbaarheidszones)	Het SQL-proces wordt opnieuw opgestart op dezelfde VIRTUELE machine.	Het SQL-proces wordt opnieuw opgestart op een andere VIRTUELE machine.
Zakelijk cruciaal	Lokale redundantie (Enkele beschikbaarheidszone)	Het SQL-proces wordt opnieuw opgestart op de primaire replica of een willekeurige secundaire replica wordt gepromoveerd naar een primaire replica.	Niet van toepassing.
Zakelijk cruciaal	Zone-redundantie (Meerdere beschikbaarheidszones)	Het SQL-proces wordt opnieuw opgestart op de primaire replica, of de willekeurige secundaire replica wordt gepromoveerd tot primaire, zowel in dezelfde als in een andere beschikbaarheidszone.	Niet van toepassing.

Machtigingen

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

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

Een instantie opnieuw starten met een handmatige failover

U kunt een exemplaar opnieuw opstarten met een handmatige failover met behulp van PowerShell, de Azure CLI of REST API.

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

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

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
abonnements-id	Abonnements-id waarop het beheerde exemplaar wordt geïmplementeerd
naam van resourcegroep	Resourcegroep die een beheerd exemplaar bevat
managedInstanceName	Naam van beheerd exemplaar
replicaType	(Optioneel) (Primair of LeesbaarSecundair). 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.

Monitor de overschakeling

Het bewaken van de voortgang van een door de gebruiker geïnitieerde failover verschilt voor exemplaren in de servicelagen Bedrijfskritiek en Algemeen gebruik.

Als u de voortgang van een door de gebruiker geïnitieerde failover wilt controleren, gebruikt u:

sys.dm_os_sys_info om de systeemtijd voor de servicelaag Algemeen gebruik te controleren.
sys.dm_hadr_fabric_replica_states om beschikbare replica's te controleren voor het serviceniveau Bedrijfskritiek.

De laatste stap van het failoverproces is de omleiding van clientverbindingen met het nieuwe primaire knooppunt. Het korte verlies van connectiviteit van uw client tijdens de failover, meestal minder dan een minuut, geeft aan dat de failover is geslaagd, ongeacht de servicelaag.

Algemeen gebruik servicelaag

In het volgende T-SQL-voorbeeld ziet u de uptime voor het SQL-proces op het knooppunt voor de servicelaag Algemeen gebruik :

SELECT sqlserver_start_time, sqlserver_start_time_ms_ticks FROM sys.dm_os_sys_info

De begintijd van het SQL-proces is het tijdstip waarop het SQL Server-database-engineproces is gestart op het knooppunt, dat na elke failover wordt bijgewerkt. Voer deze query uit voor en nadat u een failover van een exemplaar in de servicelaag Algemeen gebruik hebt gestart om de voortgang van de failoverbewerking te bewaken.

Bedrijfskritieke servicelaag

In het volgende T-SQL-voorbeeld wordt aangegeven welk knooppunt momenteel de primaire replica is voor de servicelaag Bedrijfskritiek :

SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states

Het knooppunt waarop de primaire replica wordt gehost, wordt gewijzigd nadat de failover is voltooid. Voer deze query uit voor en nadat u een failover van een exemplaar in de servicelaag Bedrijfskritiek hebt gestart om de voortgang van de failoverbewerking te bewaken.

Opmerking

Het volledige failoverproces kan enkele minuten duren tijdens workloads met hoge intensiteit, omdat de instantie-engine ervoor zorgt dat transacties op het secundaire knooppunt worden opgevangen bij de transacties van het primaire knooppunt voordat de failover wordt gestart.

Beperkingen

Houd rekening met de volgende functionele beperkingen van door de gebruiker geïnitieerde handmatige failovers:

Er kan slechts één (1) failover worden geïnitieerd op dezelfde SQL Managed Instance elke 15 minuten.
Failovers zijn niet toegestaan.
- Totdat de eerste volledige back-up voor een nieuwe database is voltooid door geautomatiseerde back-upsystemen.
- als er een databaseherstel wordt uitgevoerd.
Voor gevallen in de bedrijfskritische servicelaag:
- Replica's moeten een quorum hebben voordat een failoveraanvraag wordt geaccepteerd.
- De Invoke-AzSqlInstanceFailover opdracht voert een failover uit van de primaire replica, tenzij -ReadableSecondary deze is opgegeven, in welk geval de leesbare secundaire replica een failover-overschakeling uitvoert. De niet-leesbare secundaire kopieën voeren geen overstap uit wanneer deze opdracht wordt uitgevoerd.

Kom meer te weten over het testen van uw toepassingen op klaarheid voor de cloud met de video App-cloudgereedheid testen voor failovertolerantie met SQL Managed Instance.
Meer informatie over de hoge beschikbaarheid van beheerde instanties Hoge beschikbaarheid voor Azure SQL Managed Instance.
Zie voor een overzicht Wat is Azure SQL Managed Instance?.

Feedback

Is deze pagina nuttig?

Last updated on 2025-04-16