Riavviare un'istanza con un failover manuale avviato dall'utente - Istanza gestita di SQL di Azure

Si applica a: Istanza gestita di SQL di Azure SQL

Questo articolo illustra come riavviare Istanza gestita di SQL di Azure eseguendo un failover manuale avviato dall'utente in un nodo di calcolo secondario usando PowerShell, l'interfaccia della riga di comando di Azure o l'API REST.

Questo articolo spiega come eseguire il failover manuale di un nodo primario nei livelli di servizio Utilizzo generico (GP) e Business Critical (BC) ed eseguire il failover manuale di un nodo secondario di replica di sola lettura in un livello di servizio soltanto BC.

La disponibilità, una parte fondamentale della piattaforma Istanza gestita di SQL, funziona in modo trasparente per le applicazioni di database fornendo nodi di calcolo standby locali per ospitare il processo del motore di database di SQL Server. Un failover si verifica quando il processo del motore di database di SQL Server viene portato offline nel nodo di calcolo primario e viene portato online in un nodo di calcolo secondario. In genere, i failover tra i nodi di calcolo dell'istanza gestita di SQL sono automatici e gestiti dalla piattaforma quando viene rilevato un errore, un nodo è danneggiato o durante gli aggiornamenti software mensili regolari.

L'intera operazione di failover consiste nel portare online il processo del motore di database di SQL Server in un nodo secondario, convalidando lo stato del database e quindi reindirizzando infine le connessioni client al nuovo nodo primario. Le connessioni client hanno esito negativo solo per un breve periodo di tempo, in genere inferiore a un minuto, durante il passaggio finale dell'operazione di failover.

È possibile eseguire un failover manuale per riavviare il processo del motore in un nodo diverso per i motivi seguenti:

• Accessi non riusciti o lentezza a causa di problemi di prestazioni.
• 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.
• Riduzione delle prestazioni delle query (il riavvio dell'istanza può contribuire a ridurre il problema di prestazioni).

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. Per altre informazioni sul test delle applicazioni per la conformità al cloud, vedere il video seguente:

La tabella seguente descrive il comportamento previsto di Istanza gestita di SQL durante un'operazione di failover in base al livello di servizio e al modello di disponibilità:

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

È possibile riavviare un’istanza eseguendo un failover manuale usando PowerShell, l'interfaccia della riga di comando di Azure o l'API REST.

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

Connect-AzAccount
Select-AzSubscription -SubscriptionId $subscription

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

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

az sql mi failover -g myresourcegroup -n myinstancename

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

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

Il monitoraggio dello stato di avanzamento di un failover avviato dall'utente differisce per le istanze nei livelli di servizio Business Critical e Utilizzo generico.

Per monitorare lo stato di avanzamento di un failover avviato dall'utente, usare:

• sys.dm_os_sys_info per controllare il tempo di attività del sistema per il livello di servizio Utilizzo generico.
• sys.dm_hadr_fabric_replica_states per controllare le repliche disponibili per il livello di servizio Business Critical.

Il passaggio finale del processo di failover è il reindirizzamento delle connessioni client al nuovo nodo primario. La breve perdita di connettività dal client durante il failover, che in genere dura meno di un minuto, indica che il failover è riuscito correttamente indipendentemente dal livello di servizio.

L'esempio T-SQL seguente mostra il tempo di attività per il processo SQL nel nodo per il livello di servizio Utilizzo generico:

SELECT sqlserver_start_time, sqlserver_start_time_ms_ticks FROM sys.dm_os_sys_info

L'ora di inizio del processo SQL è l'ora in cui il processo del motore di database di SQL Server è stato avviato nel nodo. Il tempo viene riavviato al termine del failover. Eseguire questa query prima e dopo aver avviato un failover di un'istanza nel livello di servizio Utilizzo generico per monitorare lo stato di avanzamento dell'operazione di failover.

L'esempio T-SQL seguente indica quale nodo è attualmente la replica primaria per il livello di servizio Business Critical:

SELECT DISTINCT replication_endpoint_url, fabric_replica_role_desc FROM sys.dm_hadr_fabric_replica_states

Il nodo che ospita la replica primaria cambia dopo il completamento del failover. Eseguire questa query prima e dopo aver avviato un failover di un'istanza nel livello di servizio Business Critical per monitorare lo stato di avanzamento dell'operazione di failover.

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

• Potrebbe esservi un (1) failover avviato nella stessa Istanza gestita di SQL ogni 15 minuti.
• I failover non sono consentiti:
  • Finché il primo backup completo di un nuovo database non viene completato dai sistemi di backup automatizzati.
  • se è in corso il ripristino del database.
• Per le istanze nel livello di servizio Business Critical:
  • Deve esistere un quorum di repliche affinché la richiesta di failover venga accettata.
  • Non è possibile specificare la replica secondaria leggibile in cui avviare il failover.

• 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.
• Altre informazioni sulla disponibilità elevata dell'istanza gestita in Disponibilità elevata per Istanza gestita di SQL di Azure.
• Per una panoramica, vedere Cos'è Istanza gestita di SQL di Azure?.