Condividi tramite

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

  • Articolo

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.

Nota

Il failover in questo articolo fa riferimento all'avvio del processo del motore di database di SQL Server in un nodo secondario e non è correlato al failover tra aree di un gruppo di failover.

Quando usare il failover manuale

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à:

Livello di servizio Modello di disponibilità Comportamento di failover previsto Potenziale comportamento di failover (eccezioni)
Utilizzo generico Ridondanza locale
(Singola zona di disponibilità)		 Il processo SQL viene riavviato nella stessa macchina virtuale. Il processo SQL viene riavviato in una macchina virtuale diversa.
Utilizzo generico Ridondanza della zona (anteprima)
(Più zone di disponibilità)		 Il processo SQL viene riavviato nella stessa macchina virtuale. Il processo SQL viene riavviato in una macchina virtuale diversa.
Business Critical Ridondanza locale
(Singola zona di disponibilità)		 La replica secondaria casuale viene promossa a primaria. N/D
Business Critical Ridondanza della zona
(Più zone di disponibilità)		 La replica secondaria casuale viene promossa a primaria nella stessa zona di disponibilità o in una zona di disponibilità diversa. N/D

Autorizzazioni

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

Riavviare un'istanza con un failover manuale

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

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

Monitorare il failback

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.

Livello di servizio Utilizzo generico

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.

Livello di servizio Business Critical

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.

Nota

Il completamento del processo di failover completo potrebbe richiedere alcuni minuti durante carichi di lavoro ad alta intensità perché il motore di istanze garantisce che le transazioni nel nodo secondario vengano intercettati nelle transazioni dal nodo primario prima di avviare il failover.

Limiti

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.

Contenuto correlato