Dela via

Redundanslänk – Azure SQL Managed Instance

Applies to:Azure SQL Managed Instance

I den här artikeln lär du dig hur du växlar över en databas länkad mellan SQL Server och Azure SQL Managed Instance med hjälp av SQL Server Management Studio (SSMS) eller PowerShell för katastrofåterställning eller migrering.

Förutsättningar

Om du vill växla över dina databaser till din sekundära replika via länken, behöver du följande krav:

Stoppa arbetsbelastning

Om du är redo att redundansväxla databasen till den sekundära repliken stoppar du först alla programarbetsbelastningar på den primära repliken under underhållstimmarna. Detta gör att databasreplikeringen kan komma ikapp den sekundära så att du kan redundansväxla till den sekundära utan dataförlust. Se till att dina program inte genomför transaktioner till den primära databasen innan de växlar över.

Kontrollera replikeringsfördröjningen

Det är viktigt att den sekundära repliken kommer ikapp den primära repliken innan du utför en planerad redundansväxling. Planerad redundans kan överskrida tidsgränsen och misslyckas om den sekundära repliken ligger långt efter den primära repliken.

Använd följande T-SQL-fråga på både SQL Server och SQL Managed Instance för att övervaka replikeringsfördröjningen mellan replikerna:

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   ag.name [Link name], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

Om replikeringsfördröjningen är hög väntar du på att den sekundära repliken ska komma ikapp den primära repliken. Du kan behöva utföra ytterligare felsökningssteg om fördröjningen kvarstår, till exempel förbättra länknätverkets dataflöde mellan de två instanserna eller öka resurskapaciteten på den sekundära repliken.

Övergå till en annan databas vid fel

Du kan redundansväxla en länkad databas med hjälp av Transact-SQL (T-SQL), SQL Server Management Studio eller PowerShell.

Du kan växla över länken med hjälp av Transact-SQL från och med SQL Server 2022 CU13 (KB5036432).

Om du vill utföra en planerad redundansväxling för en länk använder du följande T-SQL-kommando på den primära repliken:

ALTER AVAILABILITY GROUP [<DAGname>] FAILOVER

Om du vill utföra en tvingad redundansväxling använder du följande T-SQL-kommando på den sekundära repliken:

ALTER AVAILABILITY GROUP [<DAGname>] FORCE_FAILOVER_ALLOW_DATA_LOSS

Viktig

Efter att ha utfört en planerad omställning är replikeringsläget inställt på asynkront.

Övergång vid avbrott för flera databaser

Om du planerar att redundansväxla flera databaser från instanser på samma server, för optimal prestanda och förutsägbarhet, redundansväxla över 8 databaser per instans åt gången. Om du till exempel har 10 instanser med 32 länkade databaser vardera, växla över 8 databaser åt gången från varje instans och upprepa processen tills alla databaser har växlats över.

Visa databas efter överlämning

För SQL Server 2022, om du valde att behålla länken, kan du kontrollera att den distribuerade tillgänglighetsgruppen finns under Tillgänglighetsgrupper i Objektutforskaren i SQL Server Management Studio.

Om du tappade länken under redundansväxlingen kan du använda Object Explorer för att bekräfta att den distribuerade tillgänglighetsgruppen inte längre finns. Om du väljer att behålla tillgänglighetsgruppen är databasen fortfarande Synkroniserad.

Rensa efter redundansväxling

Såvida inte Ta bort länk efter lyckad redundansväxling har valts, bryter inte redundansväxling med SQL Server 2022 länken. Du kan behålla länken efter failover, vilket håller tillgänglighetsgruppen och den distribuerade tillgänglighetsgruppen aktiva. Ingen ytterligare åtgärd krävs.

Att släppa länken tar bara bort den distribuerade tillgänglighetsgruppen och lämnar tillgänglighetsgruppen aktiv. Du kan välja att behålla tillgänglighetsgruppen eller släppa den.

Om du väljer att släppa tillgänglighetsgruppen ersätter du följande värde och kör sedan T-SQL-exempelkoden:

  • <AGName> med namnet på tillgänglighetsgruppen på SQL Server (används för att skapa länken).
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <AGName> 
GO

Inkonsekvent tillstånd efter tvingad omkoppling

Efter en tvingad övergång kan du stöta på en split-brain-situation där båda replikerna är i den primära rollen, vilket lämnar länken inkonsekvent. Detta kan inträffa om du växlar över till den sekundära repliken under ett haveri, och sedan kommer den primära repliken tillbaka online.

Information om hur du löser det här problemet finns i Lös split-brain-scenario.

Relaterat innehåll

Så här använder du länken:

Om du vill veta mer om länken:

Överväg följande för andra replikerings- och migreringsscenarier:

  • Last updated on