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
Istanza gestita di SQL di Azure SQL