För att övergå måste du först ändra replikeringslägena för SQL Server-instansen med hjälp av Transact-SQL (T-SQL).
Sedan kan du utföra failover och växla roller med hjälp av PowerShell.
Växla replikeringsläge (redundans till SQL MI)
Replikeringen mellan SQL Server och SQL Managed Instance är asynkron som standard. Om du överför från SQL Server till Azure SQL Managed Instance, innan du överför din databas, växla länken till synkront läge på SQL Server med hjälp av Transact-SQL (T-SQL).
Not
- Hoppa över det här steget om du överför från SQL Managed Instance till SQL Server 2022.
- Synkron replikering över stora nätverksavstånd kan göra transaktionerna på den primära repliken långsammare.
Kör följande T-SQL-skript på SQL Server för att ändra replikeringsläget för den distribuerade tillgänglighetsgruppen från asynkronisering till synkronisering. Ersätta:
-
<DAGName> med namnet på den distribuerade tillgänglighetsgruppen (används för att skapa länken).
-
<AGName> med namnet på tillgänglighetsgruppen som skapats på SQL Server (används för att skapa länken).
-
<ManagedInstanceName> med namnet på den hanterade instansen.
-- 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);
Om du vill bekräfta att du har ändrat länkens replikeringsläge använder du följande dynamiska hanteringsvy. Resultaten visar SYNCHRONOUS_COMMIT-tillståndet.
-- 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 när du har bytt SQL Server till synkront incheckningsläge är replikeringen mellan de två instanserna synkron. Om du behöver återställa det här tillståndet följer du samma steg och anger AVAILABILITY_MODE till ASYNCHRONOUS_COMMIT.
Kontrollera LSN-värden på både SQL Server och SQL Managed Instance
Bekräfta att replikeringen till den sekundära är klar och slutför failover eller migreringen. För detta kontrollerar du att loggsekvensnumren (LSN) i loggposterna för både SQL Server och SQL Managed Instance är desamma.
Inledningsvis förväntas LSN på den primära vara högre än LSN på den sekundära. Nätverksfördröjning kan leda till att replikeringen ligger något efter den primära. Eftersom arbetsbelastningen har stoppats på den primära servern kommer LSN:erna att matcha och sluta ändras efter en viss tid.
Använd följande T-SQL-fråga på SQL Server för att läsa LSN för den senaste registrerade transaktionsloggen. Ersätta:
-
<DatabaseName> med ditt databas-namn och leta efter det senaste härdade LSN-numret.
-- 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>'
Använd följande T-SQL-fråga på SQL Managed Instance för att läsa den senaste härdade LSN för databasen. Ersätt <DatabaseName> med databasnamnet.
Den här frågan fungerar på en sql-hanterad instans för generell användning. För en affärskritisk SQL-hanterad instans, ta bort kommentarstecknen runt and drs.is_primary_replica = 1 i slutet av skriptet. På tjänstnivån Affärskritisk ser detta filter till att detaljer endast läses från den primära repliken.
-- 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
Du kan också använda Get-AzSqlInstanceLink PowerShell eller az sql mi link show Azure CLI-kommando för att hämta egenskapen LastHardenedLsn för din länk i SQL Managed Instance för att ange samma information som föregående T-SQL-fråga.
Viktig
Bekräfta återigen att din arbetsbelastning har stoppats på den primära servern. Kontrollera att LSN:er på både SQL Server och SQL Managed Instance matchar och att de förbli matchade och oförändrade under en tid. Stabila LSN:er på båda instanserna indikerar att tail-loggen har replikerats till den sekundära instansen och att arbetsbelastningen har stoppats effektivt.
Växla över vid fel för en databas
Om du vill använda PowerShell för att redundansväxla en databas mellan SQL Server 2022 och SQL Managed Instance samtidigt som du behåller länken, eller om du vill utföra en redundansväxling med dataförlust för någon version av SQL Server, använder du guiden redundansväxling mellan SQL Server och Managed Instance i SSMS för att generera skriptet för din miljö. Du kan utföra en planerad överflyttning från den primära eller sekundära repliken. Om du vill göra en tvingad redundansväxling ansluter du till den sekundära repliken.
Om du vill bryta länken och stoppa replikeringen när du redundansväxlar eller migrerar databasen oavsett SQL Server-version använder du kommandot Remove-AzSqlInstanceLink PowerShell eller az sql mi link delete Azure CLI.
Försiktighet
- Innan du redundansväxlar stoppar du arbetsbelastningen på källdatabasen så att den replikerade databasen kan komma ifatt och redundansväxla helt utan dataförlust. Om du utför en tvingad failover, eller om du bryter länken innan LSN:er matchar, kan du förlora data.
- Omställning av en databas i SQL Server 2019 och tidigare versioner bryter och tar bort länken mellan de två replikorna. Du kan inte återgå till det ursprungliga primärsystemet.
Följande exempelskript bryter länken och avslutar replikeringen mellan dina repliker, vilket gör att databasen läser/skriver på båda instanserna. Ersätta:
-
<ManagedInstanceName> med namnet på den hanterade instansen.
-
<DAGName> med namnet på länken du växlar över (utdata från egenskapen Name från kommandot Get-AzSqlInstanceLink som kördes tidigare).
# 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
När redundansväxlingen lyckas tas länken bort och finns inte längre. SQL Server-databasen och SQL Managed Instance-databasen kan båda köra läs-/skrivarbetsbelastningar eftersom de nu är helt oberoende.
Viktig
Efter att redundansväxlingen till SQL Managed Instance har genomförts, uppdatera manuellt din applikations anslutningssträng till SQL Managed Instance FQDN för att slutföra migreringen eller redundansväxlingen och fortsätta körningen i Azure.
När länken har släppts kan du behålla tillgänglighetsgruppen på SQL Server, men du måste släppa distribuerade tillgänglighetsgrupp för att ta bort länkmetadata från SQL Server. Det här ytterligare steget är bara nödvändigt när du överväxlar med hjälp av PowerShell eftersom SSMS utför den här åtgärden åt dig.
Om du vill släppa din distribuerade tillgänglighetsgrupp ersätter du följande värde och kör sedan T-SQL-exempelkoden:
-
<DAGName> med namnet på den distribuerade tillgänglighetsgruppen på SQL Server (används för att skapa länken).
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName>
GO
Azure SQL Managed Instance