Přepínací propojení – Azure SQL Managed Instance

Applies to:Azure SQL Managed Instance

V tomto článku se dozvíte, jak provést převzetí služeb při selhání databáze linked mezi SQL Serverem a Azure SQL Managed Instance pomocí SQL Server Management Studio (SSMS) nebo PowerShellu pro účely havarijního zotavení nebo migrace.

Požadavky

Pokud chcete převzít služby při selhání databází do sekundární repliky prostřednictvím odkazu, potřebujete následující požadavky:

Aktivní Azure předplatné. Pokud žádné nemáte, vytvořte si bezplatný účet.
Podporovaná verze SQL Serveru s nainstalovanou vyžadovanou aktualizací služby.
Propojení nakonfigurované mezi primární a sekundární replikou
Převzetí propojení při selhání můžete provést pomocí Transact-SQL počínaje SQL Server 2022 CU13 (KB5036432).

Zastavení zatížení

Pokud jste připraveni přejít na sekundární repliku databáze, nejprve zastavte všechny úlohy aplikací běžící na primární replice během doby údržby. To umožňuje replikaci databáze dohnat sekundární server, abyste mohli přejít na sekundární server bez ztráty dat. Před převzetím služeb při selhání se ujistěte, že vaše aplikace neaktuují transakce do primárního serveru.

Kontrola zpoždění replikace

Před provedením plánovaného převzetí služeb při selhání je důležité, aby sekundární replika dohnala primární repliku. Plánované převzetí služeb při selhání může vypršet časový limit a dojít k selhání, pokud sekundární replika zaostává daleko za primární.

K monitorování prodlevy replikace mezi replikami použijte následující dotaz T-SQL pro SQL Server i SQL Managed Instance:

-- 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

Pokud je prodleva replikace vysoká, počkejte, než sekundární replika dožene primární repliku. Pokud prodleva přetrvává, může být potřeba provést další kroky pro řešení potíží, jako například zlepšit propustnost sítě propojení mezi dvěma instancemi nebo zvýšit kapacitu prostředků na sekundární replice.

Převzetí služeb při selhání databáze

Propojené databáze můžete převzít při selhání pomocí Transact-SQL (T-SQL), SQL Server Management Studio nebo PowerShellu.

Převzetí propojení při selhání můžete provést pomocí Transact-SQL počínaje SQL Server 2022 CU13 (KB5036432).

Pokud chcete pro připojení provést plánované převzetí služby po selhání, použijte na primární replice následující příkaz T-SQL:

ALTER AVAILABILITY GROUP [<DAGname>] FAILOVER

Pokud chcete na sekundární replice použít následující příkaz T-SQL pro provedení vynuceného převzetí služeb při selhání, postupujte podle těchto kroků:

ALTER AVAILABILITY GROUP [<DAGname>] FORCE_FAILOVER_ALLOW_DATA_LOSS

Abyste mohli převzít roli při selhání, musíte nejprve přepnout replikační režim instance SQL Serveru pomocí Transact-SQL (T-SQL).

Poté můžete provést failover a přepnout role pomocí PowerShellu.

Přepnutí režimu replikace (přepnutí služeb do SQL MI)

Replikace mezi SQL Server a SQL Managed Instance je ve výchozím nastavení asynchronní. Pokud provádíte převzetí služeb při selhání od SQL Server na Azure SQL Managed Instance, před převzetím služeb při selhání databáze přepněte odkaz na synchronní režim na SQL Server pomocí Transact-SQL (T-SQL).

Poznámka:

Pokud provádíte přepnutí při selhání z SQL Managed Instance na SQL Server 2022, tento krok přeskočte.
Synchronní replikace napříč velkými síťovými vzdálenostmi může zpomalit transakce na primární replice.

Spuštěním následujícího skriptu T-SQL na SQL Server změňte režim replikace distribuované skupiny dostupnosti z asynchronní na synchronizaci. Nahradit:

<DAGName> s názvem distribuované skupiny dostupnosti (používá se k vytvoření odkazu).
<AGName> s názvem skupiny dostupnosti vytvořené na SQL Server (používá se k vytvoření odkazu).
<ManagedInstanceName> s názvem vaší spravované instance.

-- 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);

Pokud chcete ověřit, že jste režim replikace propojení úspěšně změnili, použijte následující zobrazení dynamické správy. Výsledky označují SYNCHRONOUS_COMMIT stav.

-- 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

Teď, když jste přepnuli SQL Server na synchronní režim potvrzení, je replikace mezi těmito dvěma instancemi synchronní. Pokud potřebujete tento stav vrátit zpět, postupujte podle stejných kroků a nastavte AVAILABILITY_MODE hodnotu ASYNCHRONOUS_COMMIT.

Kontrola hodnot LSN na SQL Server i v SQL Managed Instance

Pokud chcete dokončit převzetí služeb při selhání nebo migraci, ověřte, že je replikace do sekundárního prostředí dokončená. Pro to se ujistěte, že pořadová čísla protokolů (LSN) jsou stejná v záznamech protokolu pro SQL Server i SQL Managed Instance.

Zpočátku se očekává, že LSN primárního serveru je vyšší než LSN na sekundárním serveru. Latence sítě může způsobit, že replikace zaostává za primární instancí. Vzhledem k tomu, že zátěž byla zastavena na primárním serveru, LSN se po nějaké době budou shodovat a přestanou se měnit.

Pomocí následujícího T-SQL dotazu na SQL Serveru načtěte LSN posledního zaznamenaného transakčního logu. Nahrazení:

<DatabaseName> zadejte název databáze a vyhledejte poslední posílené číslo LSN.

-- 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>'

Následující dotaz T-SQL na SQL Managed Instance použijte ke čtení posledního posíleného LSN pro vaši databázi. Nahraďte <DatabaseName> názvem databáze.

Tento dotaz funguje na SQL Managed Instance pro obecné účely. Pro SQL Managed Instance pro důležité obchodní informace odkomentujte and drs.is_primary_replica = 1 na konci skriptu. Na úrovni služby Business Critical tento filtr zajišťuje, že podrobnosti se čtou jenom z primární repliky.

-- 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

Alternativně můžete také použít příkaz Get-AzSqlInstanceLink PowerShell nebo az sql mi link show Azure CLI k načtení vlastnosti LastHardenedLsn odkazu na SQL Managed Instance a poskytnout stejné informace jako předchozí dotaz T-SQL.

Důležité

Znovu ověřte, že je vaše úloha zastavená na primárním serveru. Zkontrolujte, že se LSN na SQL Serveru i SQL Managed Instance shodují a že zůstávají po určitou dobu v souladu a nemění se. Stabilní sítě LSN v obou instancích značí, že se protokol tail replikoval do sekundárního serveru a úloha se efektivně zastaví.

Převzetí služeb při selhání databáze

Pokud chcete použít PowerShell k převzetí služeb v případě selhání databáze mezi SQL Server 2022 a SQL Managed Instance, a přitom zachovat propojení, nebo provést převzetí služeb se ztrátou dat pro jakoukoli verzi SQL Serveru, použijte průvodce Převzetí služeb mezi SQL Serverem a Managed Instance v nástroji SSMS, který vygeneruje skript pro vaše prostředí. Plánované převzetí služeb při selhání můžete provést buď z primární nebo sekundární repliky. Pokud chcete provést vynucené převzetí služeb při selhání, připojte se k sekundární replice.

Chcete-li přerušit propojení a zastavit replikaci v případě převzetí služeb při selhání nebo migraci databáze bez ohledu na verzi serveru SQL Server, použijte příkaz Remove-AzSqlInstanceLink PowerShell nebo az sql mi link delete Azure CLI.

Upozornění

Před převzetím služeb při selhání zastavte práci ve zdrojové databázi, aby se replikovaná databáze mohla zcela synchronizovat a převzetí služeb proběhlo bez ztráty dat. Pokud provedete vynucené převzetí služeb nebo přerušíte propojení před sladěním LSN, může dojít ke ztrátě dat.
Přepnutí databáze při selhání v SQL Serveru 2019 a starších verzích přeruší a odstraní vazbu mezi těmito dvěma replikami. Nelze se vrátit k počátečnímu primárnímu.

Následující ukázkový skript přeruší propojení a ukončí replikaci mezi vašimi replikami a provede tak čtení a zápis databáze v obou instancích. Nahrazení:

<ManagedInstanceName> s názvem vaší spravované instance.
<DAGName> s názvem odkazu, který přepínáte (výstup vlastnosti Name, získaný z příkazu Get-AzSqlInstanceLink spuštěného výše).

# 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

Po úspěšném převzetí služeb při selhání se propojení zahodí a už neexistuje. Databáze SQL Server i databáze SQL Managed Instance může spouštět úlohy čtení a zápisu, protože jsou teď zcela nezávislé.

Důležité

Po úspěšném failoveru na SQL Managed Instance ručně přenastavte connection string aplikace na plně kvalifikovaný název domény (FQDN) SQL Managed Instance, abyste dokončili proces migrace nebo failoveru a pokračovali v provozu na platformě Azure.

Po vyřazení odkazu můžete skupinu dostupnosti ponechat na SQL Server, ale pokud chcete odebrat metadata propojení z SQL Server, musíte odstranit distributed skupinu dostupnosti. Tento další krok je nezbytný pouze při selhání přes PowerShell, protože SSMS provede tuto akci za vás.

Pokud chcete odstranit distribuovanou skupinu dostupnosti, nahraďte následující hodnotu a spusťte ukázkový kód T-SQL:

<DAGName> s názvem distribuované skupiny dostupnosti na SQL Server (používá se k vytvoření odkazu).

-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName> 
GO

Důležité

Po provedení plánovaného převzetí služeb při selhání je režim replikace nastavený na asynchronní.

Přepnutí při selhání více databází

Pokud plánujete převzetí více databází z instancí na stejném serveru, pro zajištění optimálního výkonu a předvídatelnosti, převezměte při selhání 8 databází na jednu instanci najednou. Pokud máte například 10 instancí s 32 propojenými databázemi, přepněte vždy 8 databází z každé instance a tento proces opakujte, dokud nebudou všechny databáze přepnuty.

Zobrazit databázi po failoveru

Pokud jste se rozhodli zachovat propojení pro SQL Server 2022, můžete zkontrolovat, jestli distribuovaná skupina dostupnosti existuje v sekci skupiny dostupnosti v Object Explorer v SQL Server Management Studio.

Pokud jste během převzetí služeb při selhání ztratili propojení, můžete pomocí Object Explorer ověřit, že distribuovaná skupina dostupnosti už neexistuje. Pokud jste se rozhodli zachovat skupinu dostupnosti, bude databáze stále synchronizovaná.

Úklid po havárii

Pokud není vybrána možnost Odstranit odkaz po úspěšném převzetí služeb při selhání, pak převzetí služeb při selhání v SQL Serveru 2022 nenaruší propojení. Propojení můžete udržovat po převzetí služeb při selhání, což zanechá skupinu dostupnosti a distribuovanou skupinu dostupnosti aktivní. Nevyžaduje se žádná další akce.

Zrušení odkazu zruší pouze distribuovanou skupinu dostupnosti, zatímco skupina dostupnosti zůstane aktivní. Můžete se rozhodnout, že skupinu dostupnosti necháte nebo ji vypustíte.

Pokud se rozhodnete odstranit skupinu dostupnosti, nahraďte následující hodnotu a spusťte ukázkový kód T-SQL:

<AGName> s názvem skupiny dostupnosti na SQL Server (používá se k vytvoření odkazu).

-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <AGName> 
GO

Nekonzistentní stav po vynuceném převzetí při selhání

Po vynuceném převzetí služeb při selhání můžete narazit na scénář rozděleného mozku, ve kterém jsou obě repliky v primární roli, takže propojení zůstane v nekonzistentním stavu. K tomu může dojít, když dojde k převedení na sekundární repliku během havárie a pak se primární replika opět připojí.

Pokud chcete tento problém vyřešit, přečtěte si téma Oprava scénáře rozděleného mozku.

Použití odkazu:

Další informace o odkazu:

Přehled propojení Managed Instance
Obnova po havárii s odkazem na instanci Managed Instance

V případě jiných scénářů replikace a migrace zvažte následující:

Váš názor

Byla tato stránka užitečná?

Last updated on 2026-04-14

Přepínací propojení – Azure SQL Managed Instance

Požadavky

Zastavení zatížení

Kontrola zpoždění replikace

Převzetí služeb při selhání databáze

Přepnutí při selhání více databází

Zobrazit databázi po failoveru

Úklid po havárii

Nekonzistentní stav po vynuceném převzetí při selhání

Související obsah

Váš názor

Další materiály