Als u een failover wilt uitvoeren, moet u eerst de replicatiemodi van het SQL Server-exemplaar overschakelen met behulp van Transact-SQL (T-SQL).
Vervolgens kunt u een failover uitvoeren en schakelen tussen rollen met behulp van PowerShell.
Replicatiemodus overschakelen (failover naar SQL MI)
Replicatie tussen SQL Server en SQL Managed Instance is standaard asynchroon. Als u een failover uitvoert van van SQL Server naar Azure SQL Managed Instance, schakelt u voordat u een failover van uw database uitvoert, de koppeling over naar de synchrone modus op SQL Server met behulp van Transact-SQL (T-SQL).
Notitie
- Sla deze stap over als u een failover uitvoert van SQL Managed Instance naar SQL Server 2022.
- Synchrone replicatie tussen grote netwerkafstanden kan transacties op de primaire replica vertragen.
Voer het volgende T-SQL-script uit op SQL Server om de replicatiemodus van de gedistribueerde beschikbaarheidsgroep te wijzigen van asynchroon om te synchroniseren. Vervangen:
-
<DAGName> met de naam van de gedistribueerde beschikbaarheidsgroep (gebruikt om de koppeling te maken).
-
<AGName> met de naam van de beschikbaarheidsgroep die is gemaakt op SQL Server (gebruikt om de koppeling te maken).
-
<ManagedInstanceName> met de naam van uw beheerde exemplaar.
-- 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);
Gebruik de volgende dynamische beheerweergave om te bevestigen dat u de replicatiemodus van de koppeling hebt gewijzigd. Resultaten geven de status SYNCHRONOUS_COMMIT aan.
-- 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
Nu u SQL Server hebt overgeschakeld naar de synchrone doorvoermodus, is replicatie tussen de twee exemplaren synchroon. Als u deze status wilt omkeren, volgt u dezelfde stappen en stelt u de AVAILABILITY_MODE in op ASYNCHRONOUS_COMMIT.
LSN-waarden controleren op zowel SQL Server als SQL Managed Instance
Controleer of de replicatie naar de secundaire is voltooid om de failover of migratie te voltooien. Zorg ervoor dat de logboekreeksnummers (LSN's) in de logboekrecords voor zowel SQL Server als SQL Managed Instance hetzelfde zijn.
In eerste instantie wordt verwacht dat de LSN op de primaire waarde hoger is dan de LSN op de secundaire. Netwerklatentie kan ertoe leiden dat replicatie enigszins achterloopt op de primaire. Omdat de werklast is gestopt op de primaire server, komen de LSN's na enige tijd overeen en houden ze op met wijzigen.
Gebruik de volgende T-SQL-query op SQL Server om de LSN van het laatst geregistreerde transactielogboek te lezen. Vervangen:
- Vervang
<DatabaseName> door uw databasenaam en zoek naar het laatst geharde LSN-nummer.
-- 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>'
Gebruik de volgende T-SQL-query op SQL Managed Instance om de laatst geharde LSN voor uw database te lezen. Vervang <DatabaseName> door de naam van uw database.
Deze query werkt op een sql Managed Instance voor algemeen gebruik. Voor een Business Critical SQL Managed Instance moet u and drs.is_primary_replica = 1 aan het einde van het script de-commentariëren. Op de servicelaag Bedrijfskritiek zorgt dit filter ervoor dat details alleen worden gelezen uit de primaire replica.
-- 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
U kunt ook de Get-AzSqlInstanceLink PowerShell of az sql mi link show Azure CLI-opdracht gebruiken om de LastHardenedLsn eigenschap voor uw koppeling op SQL Managed Instance op te halen om dezelfde informatie te verkrijgen als de vorige T-SQL-query.
Belangrijk
Controleer nogmaals of uw werklast is gestopt op het primaire systeem. Controleer of LSN's op zowel SQL Server als SQL Managed Instance overeenkomen en dat ze blijven overeenkomen en enige tijd ongewijzigd blijven. Stabiele LSN's op beide exemplaren geven aan dat het staartlog is gerepliceerd naar de secundaire server en dat de werkbelasting effectief is gestopt.
Failover bij een database
Als u powerShell wilt gebruiken om een failover uit te voeren voor een database tussen SQL Server 2022 en SQL Managed Instance terwijl u de koppeling nog steeds onderhoudt of als u een failover wilt uitvoeren met gegevensverlies voor een versie van SQL Server, gebruikt u de failover tussen SQL Server en Managed Instance wizard in SSMS om het script voor uw omgeving te genereren. U kunt een geplande failover uitvoeren vanaf de primaire of secundaire replica. Als u een geforceerde failover wilt uitvoeren, maakt u verbinding met de secundaire replica.
Gebruik de Remove-AzSqlInstanceLink PowerShell- of az sql mi link delete Azure CLI-commando om de koppeling te verbreken en de replicatie te stoppen wanneer u een failover uitvoert of de database migreert, onafhankelijk van de SQL Server-versie.
Voorzichtigheid
- Voordat u een failover uitvoert, stopt u de workload op de brondatabase om de gerepliceerde database volledig in te halen en failover uit te voeren zonder gegevensverlies. Als u een geforceerde failover uitvoert of als u de koppeling onderbreekt voordat LSN's overeenkomen, verliest u mogelijk gegevens.
- Een failover van een database in SQL Server 2019 en eerdere versies wordt verbroken en de koppeling tussen de twee replica's wordt verwijderd. U kunt geen failback uitvoeren naar de eerste primaire.
Met het volgende voorbeeldscript wordt de koppeling verbroken en wordt de replicatie tussen uw replica's beëindigd, waardoor de database op beide exemplaren kan worden gelezen/geschreven. Vervangen:
-
<ManagedInstanceName> met de naam van uw beheerde instantie.
-
<DAGName> met de naam van de koppeling waarvoor u een failover uitvoert (uitvoer van de eigenschap Name van Get-AzSqlInstanceLink opdracht die eerder hierboven is uitgevoerd).
# 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
Wanneer de failover is geslaagd, wordt de koppeling verwijderd en bestaat deze niet meer. De SQL Server-database en de SQL Managed Instance-database kunnen zowel lees-/schrijfworkloads uitvoeren als ze nu volledig onafhankelijk zijn.
Belangrijk
Nadat de failover naar SQL Managed Instance is geslaagd, kunt u de verbindingsreeks van uw toepassing(en) handmatig naar de FQDN van het beheerde SQL-exemplaar verwijzen om de migratie te voltooien of een failover-overschakeling uit te voeren en door te gaan met het uitvoeren in Azure.
Nadat de koppeling is verwijderd, kunt u de beschikbaarheidsgroep op SQL Server behouden, maar u moet de gedistribueerde beschikbaarheidsgroep verwijderen om metagegevens van koppelingen uit SQL Server te verwijderen. Deze extra stap is alleen nodig wanneer u een failover uitvoert met behulp van PowerShell, omdat SSMS deze actie voor u uitvoert.
Als u de gedistribueerde beschikbaarheidsgroep wilt verwijderen, vervangt u de volgende waarde en voert u vervolgens de T-SQL-voorbeeldcode uit:
-
<DAGName> met de naam van de gedistribueerde beschikbaarheidsgroep op SQL Server (gebruikt om de koppeling te maken).
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName>
GO
Azure SQL Managed Instance