Collegamento di failover - Istanza gestita di SQL di Azure

Si applica a: Istanza gestita di SQL di Azure SQL

Questo articolo illustra come eseguire il failover di un database collegato tra SQL Server e Istanza gestita di SQL di Azure usando la funzionalità di collegamento in SQL Server Management Studio (SSMS) o PowerShell.

Nota

• La configurazione di Istanza gestita di SQL di Azure come database primario iniziale è attualmente in anteprima e supportata solo a partire da SQL Server 2022 CU10.

Prerequisiti

Per eseguire il failover dei database nella replica secondaria tramite il collegamento sono necessari i prerequisiti seguenti:

• Una sottoscrizione di Azure attiva. Se non se ne ha una, creare un account gratuito.
• Versione supportata di SQL Server con l’aggiornamento del servizio richiesto installato.
• Collegamento configurato tra la replica primaria e quella secondaria.

Interrompere il carico di lavoro

Se si è pronti per eseguire il failover del database nella replica secondaria, interrompere prima qualsiasi carico di lavoro dell’applicazione nella replica primaria durante le ore di manutenzione. Ciò consente alla replica di database di recuperare il database secondario per effettuare il failover del database secondario senza perdita di dati. Assicurarsi che le applicazioni non eseguano il commit delle transazioni nella replica primaria prima del failover.

Eseguire il failover di un database

È possibile eseguire il failover di un database collegato usando SQL Server Management Studio o PowerShell.

SQL Server Management Studio (SSMS)

Usare la procedura guidata Failover tra SQL Server e Istanza gestita in SSMS per effettuare il failover del database dal database primario alla replica secondaria.

È possibile eseguire un failover pianificato dalla replica primaria o da quella secondaria. Per eseguire un failover forzato, connettersi alla replica secondaria.

Attenzione

• Prima del failover, interrompere il carico di lavoro nel database di origine per consentire al database replicato di recuperare ed eseguire completamente il failover senza perdita di dati. Un failover forzato potrebbe comportare una perdita di dati.
• Se si effettua il failover di un database in SQL Server 2019 e versioni precedenti, il collegamento tra le due repliche viene interrotto e rimosso. Il failback al database primario iniziale non è consentito.
• Il failover di un database con il contestuale mantenimento del collegamento con SQL Server 2022 è attualmente in anteprima.

Per effettuare il failover del database, attenersi alla procedura seguente:

1. Aprire SSMS e connettersi a una delle due repliche.

2. In Esplora oggetti fare clic con il pulsante destro del mouse sul database replicato, passare il puntatore sul collegamento a Istanza gestita di SQL di Azure e scegliere Failover... per aprire la procedura guidata Failover tra SQL Server e Istanza gestita. Se sono presenti più collegamenti dallo stesso database, espandere Gruppi di disponibilità sotto Gruppi di disponibilità AlwaysOn in Esplora oggetti e fare clic con il pulsante destro del mouse sul gruppo di disponibilità distribuito per il collegamento di cui si vuole effettuare il failover. Selezionare Failover… per aprire la procedura guidata Failover tra SQL Server e Istanza gestita per tale collegamento specifico.

   

3. Nella pagina Introduzione, seleziona Avanti.

4. Nella pagina Scegli tipo di failover vengono visualizzati i dettagli relativi a ogni replica, al ruolo del database selezionato e ai tipi di failover supportati. È possibile avviare il failover da qualsiasi replica. Se si sceglie un failover forzato, è necessario selezionare la casella per indicare che potrebbe verificarsi una potenziale perdita di dati. Seleziona Avanti.

   Nota

   Se si esegue la migrazione a Istanza gestita di SQL di Azure, scegliere Failover pianificato.

5. Nella pagina Accedi ad Azure e Istanza remota:

   1. Selezionare Accedi per fornire le credenziali e accedere all’account Azure.
   2. In base al tipo di failover selezionato nella pagina precedente, l'opzione Accedi funziona in modo diverso. Per un failover pianificato, l'accesso all'istanza remota (SQL Server o Istanza gestita di SQL) è obbligatorio. Per un failover forzato, la firma è facoltativa perché sono supportati i due scenari seguenti:
      • Vero ripristino di emergenza: poiché l'istanza primaria in genere non è disponibile durante una vera emergenza, l'accesso non è possibile e l'utente deve eseguire immediatamente il failover all'istanza secondaria, rendendola la nuova istanza primaria. Dopo aver risolto l'interruzione, il collegamento è in uno stato incoerente perché entrambe le repliche sono ora nel ruolo primario (scenario split-brain).
      • Esercitazione sul ripristino di emergenza: l'esecuzione di esercitazioni sul ripristino di emergenza con failover forzato è sconsigliata perché potrebbe verificarsi una potenziale perdita di dati. Tuttavia, durante un'esercitazione, poiché l'istanza primaria è disponibile, l'accesso è supportato e si ha la possibilità di invertire i ruoli per entrambe le repliche per evitare lo scenario split-brain.

6. Nella pagina Operazioni post-failover le opzioni variano tra SQL Server 2022 e versioni precedenti e se è stato possibile connettersi o meno all'istanza primaria.

   • Nel caso di SQL Server 2022, è possibile scegliere di arrestare la replica tra repliche ed eliminare il collegamento e il gruppo di disponibilità distribuito al termine del failover. Se si vuole mantenere il collegamento e continuare a replicare i dati tra le repliche, lasciare la casella deselezionata. Se si sceglie di eliminare il collegamento è anche possibile selezionare la casella per eliminare il gruppo di disponibilità, se è stato creato esclusivamente allo scopo di replicare il database in Azure e non è più necessario. Selezionare le caselle che soddisfano lo scenario e poi Avanti.
   • Per SQL Server 2019 e versioni precedenti, l’opzione Rimuovi il collegamento è selezionata per impostazione predefinita e non è possibile deselezionarla, perché il failover a Istanza gestita di SQL arresta la replica, interrompe il collegamento ed elimina il gruppo di disponibilità distribuito. Selezionare la casella per indicare che il collegamento verrà eliminato, quindi selezionare Avanti.
   • (Facoltativamente) Se è stato possibile accedere all'istanza di SQL Server nella pagina precedente, è anche possibile eliminare il gruppo di disponibilità nell'istanza di SQL Server dopo un failover forzato selezionando la casella nella sezione Pulizia.

7. Nella pagina Riepilogo esaminare le azioni. Facoltativamente, è possibile selezionare Script per generare uno script in modo da poter effettuare facilmente il failover del database usando lo stesso collegamento in futuro. Selezionare Fine quando si è pronti a effettuare il failover del database.

8. Al termine di tutti i passaggi, nella pagina Risultati vengono visualizzati i segni di spunta accanto alle azioni completate correttamente. Ora è possibile chiudere la finestra.

Se si sceglie di mantenere il collegamento per SQL Server 2022, il database secondario diventa il nuovo database primario; il collegamento è ancora attivo ed è possibile eseguire il failback al database secondario.

Se si usa SQL Server 2019 e versioni precedenti o se si sceglie di eliminare il collegamento per SQL Server 2022, il collegamento viene eliminato, pertanto non esiste più dopo il completamento del failover. Il database di origine e il database di destinazione di ogni replica possono eseguire entrambi un carico di lavoro di lettura/scrittura: Sono completamente indipendenti.

Importante

Al termine del failover in Istanza gestita di SQL, ripristinare manualmente le applicazioni stringa di connessione al nome di dominio completo dell’istanza gestita di SQL per completare la migrazione o il processo di failover e continuare l’esecuzione in Azure.

PowerShell

Per eseguire il failover, è prima necessario cambiare le modalità di replica istanza di SQL Server usando Transact-SQL (T-SQL).

È poi possibile eseguire il failover e cambiare i ruoli usando PowerShell.

Passare alla modalità di replica (failover a istanza gestita di SQL)

La replica tra SQL Server e Istanza gestita di SQL è asincrona per impostazione predefinita. Se si esegue il failover da SQL Server a Istanza gestita di SQL di Azure, prima di eseguire il failover del database, impostare il collegamento in modalità sincrona in SQL Server usando Transact-SQL (T-SQL).

Nota

• Saltare questo passaggio se si esegue il failover da Istanza gestita di SQL a SQL Server 2022.
• La replica sincrona tra distanze di rete di grandi dimensioni potrebbe rallentare le transazioni nella replica primaria.

Eseguire lo script T-SQL seguente in SQL Server per modificare la modalità di replica del gruppo di disponibilità distribuito da asincrona a sincrona. Sostituire:

• <DAGName> con il nome del gruppo di disponibilità distribuito (usato per creare il collegamento).
• <AGName> con il nome del gruppo di disponibilità creato in SQL Server (usato per il creare il collegamento).
• <ManagedInstanceName> con il nome dell'istanza gestita.

-- Run on SQL Server
-- Sets the distributed availability group to a synchronous commit.
-- ManagedInstanceName example: 'sqlmi1'
USE master
GO
ALTER AVAILABILITY GROUP [<DAGName>] 
MODIFY 
AVAILABILITY GROUP ON
    '<AGName>' WITH
    (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
    '<ManagedInstanceName>' WITH
    (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);

Per verificare che la modalità di replica del collegamento sia stata modificata correttamente, usare la DMV seguente. I risultati indicano lo stato SYNCHRONOUS_COMMIT.

-- Run on SQL Server
-- Verifies the state of the distributed availability group
SELECT
    ag.name, ag.is_distributed, ar.replica_server_name,
    ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc,
    ars.operational_state_desc, ars.synchronization_health_desc
FROM
    sys.availability_groups ag
    join sys.availability_replicas ar
    on ag.group_id=ar.group_id
    left join sys.dm_hadr_availability_replica_states ars
    on ars.replica_id=ar.replica_id
WHERE
    ag.is_distributed=1

Ora che sia SQL Server è passato in modalità di sincronizzazione, la replica tra le due istanze è sincrona. Se è necessario invertire questo stato, seguire gli stessi passaggi e impostare AVAILABILITY_MODE su ASYNCHRONOUS_COMMIT.

Controllare i valori LSN sia in SQL Server che in Istanza gestita di SQL

Per completare il failover o la migrazione, verificare che la replica nell’istanza secondaria sia stata completata. A tale scopo, verificare che i numeri di sequenza del file di log (LSN) nei record di log per SQL Server e Istanza gestita di SQL siano uguali.

Inizialmente, è previsto che l'LSN nel database primario sia superiore al numero LSN sul database secondario. La latenza di rete potrebbe causare un ritardo della replica in qualche modo dietro la replica primaria. Poiché il carico di lavoro è stato arrestato nel database primario, i nomi LSN corrisponderanno e che dopo un certo periodo di tempo smetteranno di cambiare.

Usare la query T-SQL seguente in SQL Server per leggere l'LSN dell'ultimo log delle transazioni registrato. Replace:

• <DatabaseName> con il nome del database e ricerca dell'ultimo numero LSN con protezione avanzata.

-- Run on SQL Server
-- Obtain the last hardened LSN for the database on SQL Server.
SELECT
    ag.name AS [Replication group],
    db.name AS [Database name], 
    drs.database_id AS [Database ID], 
    drs.group_id, 
    drs.replica_id, 
    drs.synchronization_state_desc AS [Sync state], 
    drs.end_of_log_lsn AS [End of log LSN],
    drs.last_hardened_lsn AS [Last hardened LSN] 
FROM
    sys.dm_hadr_database_replica_states drs
    inner join sys.databases db on db.database_id = drs.database_id
    inner join sys.availability_groups ag on drs.group_id = ag.group_id
WHERE
    ag.is_distributed = 1 and db.name = '<DatabaseName>'

Usare la seguente query T-SQL su Istanza gestita di SQL per leggere l'ultimo LSN con protezione avanzata per il database. Sostituire <DatabaseName> con il nome del database.

Questa query funziona su un’Istanza gestita di SQL per utilizzo generico. Per un’Istanza gestita di SQL business critical, rimuovere il commento and drs.is_primary_replica = 1 alla fine dello script. Nel livello di servizio Business Critical questo filtro garantisce che i dettagli vengano letti solo dalla replica primaria.

-- Run on SQL managed instance
-- Obtain the LSN for the database on SQL Managed Instance.
SELECT
    db.name AS [Database name],
    drs.database_id AS [Database ID], 
    drs.group_id, 
    drs.replica_id, 
    drs.synchronization_state_desc AS [Sync state],
    drs.end_of_log_lsn AS [End of log LSN],
    drs.last_hardened_lsn AS [Last hardened LSN]
FROM
    sys.dm_hadr_database_replica_states drs
    inner join sys.databases db on db.database_id = drs.database_id
WHERE
    db.name = '<DatabaseName>'
    -- for Business Critical, add the following as well
    -- AND drs.is_primary_replica = 1

In alternativa, è anche possibile usare il comando Get-AzSqlInstanceLink di PowerShell o il comando az sql mi link show dell'interfaccia della riga di comando di Azure per recuperare la proprietà per il LastHardenedLsn collegamento in Istanza gestita di SQL per fornire le stesse informazioni della query T-SQL precedente.

Importante

Verificare di nuovo che il carico di lavoro sia stato arrestato nel database primario. Verificare che i nomi LSN in SQL Server e Istanza gestita di SQL corrispondano e che continuino a corrispondere per un certo periodo di tempo. I nomi LSN stabili in entrambe le istanze indicano che il log della parte finale è stato replicato nel database secondario e il carico di lavoro viene arrestato in modo efficace.

Eseguire il failover di un database

Se si vuole usare PowerShell per eseguire il failover di un database tra SQL Server 2022 e Istanza gestita di SQL mantenendo il collegamento o per eseguire un failover con perdita di dati per qualsiasi versione di SQL Server, usare la procedura guidata Failover tra SQL Server e Istanza gestita in SSMS per generare lo script per l'ambiente. È possibile eseguire un failover pianificato dalla replica primaria o secondaria. Per eseguire un failover forzato, connettersi alla replica secondaria.

Per interrompere il collegamento e arrestare la replica quando si esegue il failover o la migrazione del database indipendentemente dalla versione di SQL Server, usare il comando Remove-AzSqlInstanceLink di PowerShell o il comando az sql mi link delete dell'interfaccia della riga di comando di Azure.

Attenzione

• Prima del failover, arrestare il carico di lavoro nel database di origine per consentire al database replicato di recuperare completamente e eseguire il failover senza perdita di dati. Se si esegue un failover forzato o si interrompe il collegamento prima della corrispondenza con LSN, è possibile che i dati vadano persi.
• Il failover di un database in SQL Server 2019 e versioni precedenti interrompe e rimuove il collegamento tra le due repliche. Il failback al database primario iniziale non è consentito.
• Il failover di un database mantenendo il collegamento con SQL Server 2022 è attualmente in anteprima.

Lo script di esempio seguente interrompe il collegamento e termina la replica tra le repliche, rendendo il database in lettura/scrittura in entrambe le istanze. Replace:

• <ManagedInstanceName> con il nome dell'istanza gestita.
• <DAGName> con il nome del collegamento di cui si esegue il failover (output della proprietà Name del comando Get-AzSqlInstanceLink eseguito in precedenza).

# Run in Azure Cloud Shell (select PowerShell console) 
# =============================================================================
# POWERSHELL SCRIPT TO FAIL OVER OR MIGRATE DATABASE TO AZURE
# ===== Enter user variables here ====

# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"
$LinkName = "<DAGName>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Failover the specified link
Remove-AzSqlInstanceLink -ResourceGroupName $ResourceGroup |
-InstanceName $ManagedInstanceName -Name $LinkName -Force

Quando il failover ha esito positivo, il collegamento viene eliminato e non esiste più. Il database di SQL Server e il database di Istanza gestita di SQL possono entrambi eseguire carichi di lavoro in lettura/scrittura, essendo ora completamente indipendenti.

Importante

Al termine del failover in Istanza gestita di SQL, ripristinare manualmente le applicazioni stringa di connessione al nome di dominio completo dell’istanza gestita di SQL per completare la migrazione o il processo di failover e continuare l’esecuzione in Azure.

Dopo aver eliminato il collegamento, è possibile mantenere il gruppo di disponibilità in SQL Server, ma è necessario eliminare il gruppo di disponibilità distribuito per rimuovere i metadati dei collegamenti da SQL Server. Questo passaggio aggiuntivo è necessario solo quando si esegue il failover tramite PowerShell, visto che SSMS esegue automaticamente questa azione.

Per eliminare il gruppo di disponibilità distribuito, sostituire il seguente valore e quindi eseguire il codice T-SQL di esempio:

• <DAGName> con il nome del gruppo di disponibilità distribuito in SQL Server (usato per creare il collegamento).

-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName> 
GO

Visualizzare il database dopo il failover

Per SQL Server 2022, se si sceglie di mantenere il collegamento, è possibile verificare che il gruppo di disponibilità distribuito esista in Gruppi di disponibilità in Esplora oggetti in SQL Server Management Studio.

Se il collegamento è stato eliminato durante il failover, è possibile usare Esplora oggetti per confermare che il gruppo di disponibilità distribuito non esiste più. Se si sceglie di mantenere il gruppo di disponibilità, il database verrà comunque sincronizzato.

Pulire i gruppi di disponibilità

Poiché il failover con SQL Server 2022 non interrompe il collegamento, è possibile mantenere il collegamento dopo il failover, lasciando attivo il gruppo di disponibilità e il gruppo di disponibilità distribuito. Non sono necessarie ulteriori azioni.

Tuttavia, l'eliminazione del collegamento elimina solo il gruppo di disponibilità distribuito e lascia attivo il gruppo di disponibilità. È possibile decidere di mantenere il gruppo di disponibilità o eliminarlo.

Se si decide di eliminare il gruppo di disponibilità, sostituire il seguente valore e poi eseguire il codice T-SQL di esempio:

• <AGName> con il nome del gruppo di disponibilità in SQL Server (usato per creare il collegamento).

-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <AGName> 
GO

Contenuto correlato

Per altre informazioni sul collegamento, vedere le risorse seguenti:

• Panoramica del collegamento a Istanza gestita
• Preparare l'ambiente per il collegamento di un'istanza gestita
• Configurare il collegamento tra SQL Server e istanza gestita di SQL con script
• Ripristino di emergenza con il collegamento all'istanza gestita
• Procedure consigliate per la gestione del collegamento