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.
Modifica modalità di replica (failover a SQL MI)
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 confermare che la modalità di replica del collegamento sia stata modificata correttamente, usare la seguente vista di gestione dinamica. 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 hai impostato SQL Server sulla modalità di commit sincrono, 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 sul server secondario è 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, si prevede che l'LSN sul database primario sia superiore all'LSN sul database secondario. La latenza di rete può causare un leggero ritardo della replica rispetto al primario. Poiché il carico di lavoro è stato arrestato nel database primario, gli LSN corrisponderanno e smetteranno di cambiare dopo un certo periodo di tempo.
Usare la seguente query di T-SQL su SQL Server per leggere l'LSN dell'ultimo log delle transazioni registrate. Sostituire:
-
<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>'
Usa la seguente query T-SQL su SQL Managed Instance per leggere l'ultimo LSN consolidato del tuo 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 LSN su SQL Server e sull'Istanza gestita di SQL Server corrispondano e che rimangano corrispondenti e inalterati per un certo periodo di tempo. I LSN stabili in entrambe le istanze indicano che il log finale è stato replicato al secondario e il carico di lavoro è stato effettivamente fermato.
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 da quella 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 degli LSN, potresti perdere 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.
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. Sostituire:
-
<ManagedInstanceName> con il nome dell'istanza gestita.
-
<DAGName> con il nome del collegamento su cui si effettua 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
Dopo il successo del failover all'istanza gestita di SQL, ripuntare manualmente la stringa di connessione dell'applicazione al nome di dominio completo (FQDN) 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