Failover manuale avviato dall'utente in Istanza gestita di SQL

SI APPLICA A: Istanza gestita di SQL di Azure

Questo articolo illustra come eseguire il failover manuale di un nodo primario nei livelli di servizio di SQL Istanza gestita per utilizzo generico (GP) e business critical (BC) e come eseguire manualmente il failover di un nodo di replica secondaria di sola lettura nel livello di servizio BC.

Quando usare il failover manuale

La disponibilità elevata è una parte fondamentale della piattaforma SQL istanza gestita che funziona in modo trasparente per le applicazioni di database. I failover da nodi primari a secondari in caso di riduzione del nodo o rilevamento di errori o durante gli aggiornamenti software mensili regolari rappresentano un'occorrenza prevista per tutte le applicazioni che usano SQL Istanza gestita in Azure.

È possibile considerare l'esecuzione di un failover manuale in SQL istanza gestita per alcuni dei motivi seguenti:

  • Testare l'applicazione per la resilienza del failover prima della distribuzione nell'ambiente di produzione
  • Testare i sistemi end-to-end per la resilienza degli errori nei failover automatici
  • Testare il modo in cui il failover influisca sulle sessioni di database esistenti
  • Verificare se un failover modifica le prestazioni end-to-end a causa di modifiche alla latenza di rete
  • In alcuni casi di riduzioni delle prestazioni delle query, il failover manuale consente di attenuare il problema di prestazioni.

Nota

Assicurandosi che le applicazioni siano resilienti al failover prima della distribuzione nell'ambiente di produzione, è possibile ridurre il rischio di errori dell'applicazione in produzione e contribuire alla disponibilità dell'applicazione per i clienti. Scopri di più sul test delle applicazioni per la preparazione al cloud con test della conformità del cloud per le app per la resilienza del failover con la ricodifica video di SQL istanza gestita.

Avviare il failover manuale in SQL Istanza gestita

Autorizzazioni RBAC di Azure richieste

Per avviare un failover, l'utente deve avere uno dei seguenti ruoli di Azure:

  • Ruolo di proprietario della sottoscrizione o
  • Istanza gestita ruolo Collaboratore o
  • Ruolo personalizzato con l'autorizzazione seguente:
    • Microsoft.Sql/managedInstances/failover/action

Utilizzo di PowerShell

La versione minima di AZ. SQL deve essere v 2.9.0. Si consiglia di usare Azure cloud Shell dal portale di Azure in cui è sempre disponibile la versione più recente di PowerShell.

Come prerequisito, usare lo script di PowerShell seguente per installare i moduli di Azure necessari. Inoltre, selezionare la sottoscrizione in cui si trova Istanza gestita si desidera eseguire il 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

Usare il comando PowerShell Invoke-AzSqlInstanceFailover con l'esempio seguente per avviare il failover del nodo primario, applicabile al livello di servizio BC e GP.

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

Usare il comando PS seguente per eseguire il failover del nodo secondario Read, applicabile solo al livello di servizio BC.

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

Uso dell'interfaccia della riga di comando

Assicurarsi di aver installato gli script dell'interfaccia della riga di comando più recenti.

Usare il comando AZ SQL mi failover CLI con l'esempio seguente per avviare il failover del nodo primario, applicabile al livello di servizio BC e GP.

az sql mi failover -g myresourcegroup -n myinstancename

Usare il comando dell'interfaccia della riga di comando seguente per eseguire il failover del nodo secondario Read, applicabile solo al livello di servizio BC.

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

Uso dell'API REST

Per gli utenti avanzati che potrebbero avere l'esigenza di automatizzare i failover delle istanze di SQL gestite per l'implementazione di una pipeline di testing continuo o di mitigatori delle prestazioni automatizzati, questa funzione può essere eseguita tramite l'avvio del failover tramite una chiamata API. per informazioni dettagliate, vedere istanze gestite: API REST di failover .

Per avviare il failover usando la chiamata all'API REST, generare prima il token di autenticazione usando il client API scelto. Il token di autenticazione generato viene usato come proprietà di autorizzazione nell'intestazione della richiesta API ed è obbligatorio.

Il codice seguente è un esempio dell'URI dell'API da chiamare:

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

Le proprietà seguenti devono essere passate nella chiamata API:

Proprietà API Parametro
subscriptionId ID sottoscrizione in cui viene distribuita l'istanza gestita
resourceGroupName Gruppo di risorse che contiene l'istanza gestita
managedInstanceName Nome dell'istanza gestita
replicaType Opzionale (Primario o ReadableSecondary). Questi parametri rappresentano il tipo di replica di cui eseguire il failover, ovvero primario o secondario leggibile. Se non è specificato, per impostazione predefinita il failover verrà avviato sulla replica primaria.
api-version Il valore statico e attualmente deve essere "2019-06-01-Preview"

La risposta API sarà una delle due seguenti:

  • 202 - Accettato
  • Uno degli errori 400 della richiesta.

Lo stato dell'operazione può essere rilevato tramite la revisione delle risposte API nelle intestazioni di risposta. Per altre informazioni, vedere stato delle operazioni asincrone di Azure.

Monitorare il failover

Per monitorare lo stato di failover avviato dall'utente per l'istanza di BC, eseguire la query T-SQL seguente nel client preferito, ad esempio SSMS, in SQL Istanza gestita. Verrà letta la vista di sistema sys.dm_hadr_fabric_replica_states e le repliche di report disponibili nell'istanza. Aggiornare la stessa query dopo l'avvio del failover manuale.

SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states

Prima di avviare il failover, l'output indicherà la replica primaria corrente nel livello di servizio BC contenente uno primario e tre database secondari nel gruppo di disponibilità AlwaysOn. Al momento dell'esecuzione di un failover, è necessario che l'esecuzione di questa query indichi una modifica del nodo primario.

Non sarà possibile visualizzare lo stesso output con il livello di servizio di GP come quello riportato sopra per BC. Questo perché il livello di servizio di GP si basa su un solo nodo. È possibile usare una query T-SQL alternativa che mostra l'ora in cui è stato avviato il processo SQL nel nodo per l'istanza del livello di servizio di GP:

SELECT sqlserver_start_time, sqlserver_start_time_ms_ticks FROM sys.dm_os_sys_info

La breve perdita di connettività dal client durante il failover, che in genere dura meno di un minuto, sarà l'indicazione dell'esecuzione del failover indipendentemente dal livello di servizio.

Nota

Il completamento del processo di failover (non la mancata disponibilità effettiva) potrebbe richiedere diversi minuti alla volta in caso di carichi di lavoro ad alta intensità . Questo perché il motore dell'istanza sta occupando tutte le transazioni correnti nel database primario e viene aggiornato sul nodo secondario, prima di poter eseguire il failover.

Importante

Limitazioni funzionali del failover manuale avviato dall'utente:

  • Potrebbe essere stato avviato un failover (1) nella stessa Istanza gestita ogni 15 minuti.
  • Per le istanze BC è necessario che esista il quorum delle repliche affinché venga accettata la richiesta di failover.
  • Per le istanze BC non è possibile specificare la replica secondaria leggibile su cui avviare il failover.
  • Il failover non sarà consentito fino al completamento del primo backup completo per un nuovo database da parte dei sistemi di backup automatici.
  • Il failover non sarà consentito se esiste un ripristino del database in corso.

Passaggi successivi