Eventi
31 mar, 23 - 2 apr, 23
L'ultimo evento guidato dalla community di Microsoft Fabric, Power BI, SQL e intelligenza artificiale. Dal 31 marzo al 2 aprile 2025.
Iscriviti oggi stessoQuesto browser non è più supportato.
Esegui l'aggiornamento a Microsoft Edge per sfruttare i vantaggi di funzionalità più recenti, aggiornamenti della sicurezza e supporto tecnico.
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.
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:
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 |
L'utente che avvia un failover deve disporre di uno dei ruoli di Azure seguenti:
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.
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
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_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.
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.
Le limitazioni funzionali del failover manuale avviato dall'utente sono:
Eventi
31 mar, 23 - 2 apr, 23
L'ultimo evento guidato dalla community di Microsoft Fabric, Power BI, SQL e intelligenza artificiale. Dal 31 marzo al 2 aprile 2025.
Iscriviti oggi stessoFormazione
Modulo
Informazioni su come gestire la disponibilità e il ripristino da emergenze con Istanza gestita di SQL abilitata per Azure Arc.
Certificazione
Microsoft Certified: Azure Database Administrator Associate - Certifications
Amministrare un'infrastruttura di database SQL Server per database relazionali, ibridi, locali e cloud con le offerte di database relazionali Microsoft PaaS.