Failover manuale avviato dall'utente in Istanza gestita di SQL

  • Articolo

Si applica a:Istanza gestita di SQL di Azure SQL

Questo articolo spiega come eseguire il failover manuale di un nodo primario nei livelli di servizio general purpose (GP) e business critical (BC) di Istanza gestita di SQL ed eseguire il failover manuale di un nodo secondario di replica di sola lettura in un livello di servizio soltanto BC.

Nota

Questo articolo non è correlato ai failover tra aree con gruppi di failover.

Quando usare il failover manuale

La disponibilità elevata è una parte fondamentale della piattaforma Istanza gestita di SQL, che funziona in modo trasparente per le applicazioni del database. I failover dal nodo primario ai nodi secondari in caso di riduzione delle prestazioni dei nodi o rilevamento degli errori o durante gli aggiornamenti software mensili regolari sono un'occorrenza prevista per tutte le applicazioni che usano Istanza gestita di SQL in Azure.

È possibile che si prenda in considerazione l'esecuzione di un failover manuale in Istanza gestita di SQL per alcuni dei motivi seguenti:

  • Testare la resilienza al failover dell'applicazione prima della distribuzione nell'ambiente di produzione
  • Testare la resilienza agli errori dei sistemi end-to-end nei failover automatici
  • Testare l'impatto del failover sulle sessioni di database esistenti
  • Verificare se un failover modifica le prestazioni end-to-end a causa delle modifiche apportate alla latenza di rete
  • In alcuni casi di riduzione delle prestazioni delle query, il failover manuale può contribuire a ridurre il problema di prestazioni.

Nota

Assicurarsi che le applicazioni siano resilienti al failover prima della distribuzione nell'ambiente di produzione consente di ridurre il rischio di errori dell'applicazione nell'ambiente di produzione e contribuisce alla disponibilità delle applicazioni per i clienti. Altre informazioni sul test delle applicazioni per l'idoneità al cloud con il video Test della conformità delle app cloud per la resilienza del failover con Istanza gestita di SQL.

Avviare manualmente un failover in Istanza gestita di SQL

Autorizzazioni di Controllo degli accessi in base al ruolo di Azure necessarie

L'utente che avvia un failover deve disporre di uno dei ruoli di Azure seguenti:

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

Utilizzo di PowerShell

La versione minima di Az.Sql deve essere v2.9.0. Prendere in considerazione l'uso di Azure Cloud Shell dal portale di Azure per la versione più recente di PowerShell disponibile.

Come prerequisito, usare lo script di PowerShell seguente per installare i moduli di Azure necessari. Selezionare anche la sottoscrizione in cui si trova Istanza gestita di SQL per il posizionamento del 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 Invoke-AzSqlInstanceFailover di PowerShell con il seguente esempio 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 seguente comando di PowerShell per eseguire il failover del nodo secondario in lettura, 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 più recenti dell'interfaccia della riga di comando.

Usare il comando az sql mi failover CLI con il seguente esempio 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 seguente comando della CLI per eseguire il failover del nodo secondario in lettura, 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 dover automatizzare i failover della propria Istanza gestita di SQL ai fini dell'implementazione di pipeline di test continui o di mitigazioni automatizzate delle prestazioni, questa funzione può essere eseguita tramite l'avvio del failover tramite una chiamata API. Per informazioni dettagliate, vedere Istanza gestita di SQL - API REST di failover.

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

Il codice seguente è un esempio di 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 seguenti proprietà devono essere trasferite alla chiamata API:

Proprietà API Parametro
subscriptionId ID sottoscrizione in cui viene distribuita l'istanza gestita
resourceGroupName Gruppo di ricorse che contiene l'istanza gestita
managedInstanceName Nome dell'istanza gestita
replicaType (Facoltativo) (Primary o ReadableSecondary). Questi parametri rappresentano il tipo di replica di cui eseguire il failover: primario o secondario leggibile. Se non specificato il failover viene avviato nella replica primaria per impostazione predefinita.
api-version Il valore statico deve attualmente essere "2019-06-01-preview"

L'API risponde con uno dei due valori seguenti:

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

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

Monitorare il failback

Per monitorare lo stato di avanzamento del failover avviato dall'utente per l'istanza BC, eseguire la query T-SQL seguente nel client preferito (ad esempio, SSMS) in Istanza gestita di SQL. Legge 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 indica la replica primaria corrente nel livello di servizio BC contenente un database primario e tre database secondari nel gruppo di disponibilità AlwaysOn. Dopo l'esecuzione di un failover, l'esecuzione di questa query dovrà indicare una modifica del nodo primario.

Non sarà possibile visualizzare lo stesso output con il livello di servizio GP come quello precedente illustrato per BC. Ciò avviene perché il livello di servizio GP si basa soltanto su un singolo nodo. È possibile usare una query T-SQL alternativa che mostra l'ora di avvio del processo SQL nel nodo per l'istanza del livello di servizio 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 in genere dura meno di un minuto ed è indicativa dell'esecuzione del failover indipendentemente dal livello di servizio.

Nota

Il completamento del processo di failover (e non la breve indisponibilità effettiva) potrebbe richiedere alcuni minuti alla volta in caso di carichi di lavoro ad alta intensità. Ciò è dovuto al fatto che il motore di istanze si occupa di tutte le transazioni correnti nel nodo primario e di recuperare il nodo secondario prima di poter eseguire il failover.

Importante

Le limitazioni funzionali del failover manuale avviato dall'utente sono:

  • Potrebbe esservi un failover (1) avviato nella stessa Istanza gestita di SQL ogni 15 minuti.
  • Per le istanze BC deve esistere un quorum di repliche affinché la richiesta di failover venga accettata.
  • Per le istanze BC non è possibile specificare la replica secondaria leggibile in cui avviare il failover.
  • Il failover non sarà consentito finché il primo backup completo per un nuovo database non sarà completato dai sistemi di backup automatizzati.
  • Il failover non sarà consentito se esiste un ripristino del database in corso.

Passaggi successivi