Odkaz na převzetí služeb při selhání – Azure SQL Managed Instance
Platí pro: Azure SQL Managed Instance
Tento článek vás naučí, jak převzít služby při selhání databáze propojené mezi SQL Serverem a službou Azure SQL Managed Instance pomocí aplikace SQL Server Management Studio (SSMS) nebo PowerShellu pro účely zotavení po havárii 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í předplatné Azure. Pokud žádné nemáte, vytvořte si bezplatný účet.
- Podporovaná verze SQL Serveru s nainstalovanou požadovanou aktualizací služby
- Propojení nakonfigurované mezi primární a sekundární replikou
- Propojení můžete převzít při selhání pomocí jazyka Transact-SQL počínaje SQL Serverem 2022 CU13 (KB5036432).
Zastavení úlohy
Pokud jste připraveni převzít služby při selhání databáze na sekundární repliku, zastavte nejprve všechny úlohy aplikace na primární replice během doby údržby. To umožňuje replikaci databáze zachytit sekundární, abyste mohli převzít služby při selhání sekundární 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.
Převzetí služeb při selhání databáze
Propojené databáze můžete převzít při selhání pomocí jazyka Transact-SQL (T-SQL), aplikace SQL Server Management Studio nebo PowerShellu.
Propojení můžete převzít při selhání pomocí jazyka Transact-SQL počínaje SQL Serverem 2022 CU13 (KB5036432).
Pokud chcete pro propojení provést plánované převzetí služeb při selhání, použijte na primární replice následující příkaz T-SQL:
ALTER AVAILABILITY GROUP [<DAGname>] FAILOVER
Pokud chcete provést vynucené převzetí služeb při selhání, použijte na sekundární replice následující příkaz T-SQL:
ALTER AVAILABILITY GROUP [<DAGname>] FORCE_FAILOVER_ALLOW_DATA_LOSS
Zobrazení databáze po převzetí služeb při selhání
Pokud jste se pro SQL Server 2022 rozhodli zachovat propojení, můžete zkontrolovat, že distribuovaná skupina dostupnosti existuje v části Skupiny dostupnosti v Průzkumník objektů v aplikaci SQL Server Management Studio.
Pokud jste propojení zrušili během převzetí služeb při selhání, můžete pomocí Průzkumník objektů ověřit, že distribuovaná skupina dostupnosti už neexistuje. Pokud jste se rozhodli zachovat skupinu dostupnosti, bude databáze stále synchronizovaná.
Vyčištění po převzetí služeb při selhání
Pokud není vybráno odebrání odkazu po úspěšném převzetí služeb při selhání, převzetí služeb při selhání sql Server 2022 přeruší propojení. Propojení můžete udržovat po převzetí služeb při selhání, které opustí skupinu dostupnosti a distribuovanou skupinu dostupnosti aktivní. Nevyžaduje se žádná další akce.
Přetažením odkazu se zahodí jenom distribuovaná skupina dostupnosti a 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 Serveru (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í služeb 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 v případě, že během havárie převezmete služby při selhání sekundární repliky a pak se primární replika vrátí do režimu online.
Nejprve ověřte, že jste ve scénáři rozděleného mozku. Můžete to provést pomocí aplikace SQL Server Management Studio (SSMS) nebo jazyka Transact-SQL (T-SQL).
Připojte se k SQL Serveru i spravované instanci SQL v nástroji SSMS a potom v Průzkumník objektů rozbalte repliky dostupnosti v uzlu skupiny dostupnosti ve vysoké dostupnosti AlwaysOn. Pokud jsou uvedené dvě různé repliky jako (primární), jste ve scénáři rozděleného mozku.
Případně můžete spustit následující skript T-SQL na SQL Serveru i ve spravované instanci SQL a zkontrolovat roli replik:
-- Execute on SQL Server and SQL Managed Instance
declare @link_name varchar(max) = '<DAGName>'
USE MASTER
GO
SELECT
ag.name [Link name],
rs.role_desc [Link role]
FROM
sys.availability_groups ag
join sys.dm_hadr_availability_replica_states rs
on ag.group_id = rs.group_id
WHERE
rs.is_local = 1 and ag.name = @link_name
GO
Pokud obě instance uvádějí jiný primární sloupec role Propojení, jste ve scénáři rozděleného mozku.
Pokud chcete vyřešit rozdělený stav mozku, nejprve vytvořte zálohu podle toho, která replika byla původní primární. Pokud byl původní primární server SQL Server, proveďte zálohu koncového protokolu. Pokud byla původní primární instance SQL Managed Instance, proveďte úplné zálohování pouze kopírování. Po dokončení zálohování nastavte distribuovanou skupinu dostupnosti na sekundární roli repliky, která byla původní primární, ale teď bude novou sekundární.
Například v případě skutečné havárie za předpokladu, že jste vynutili převzetí služeb při selhání úlohy SQL Serveru do služby Azure SQL Managed Instance a chcete pokračovat ve spouštění úloh ve službě SQL Managed Instance, proveďte zálohu koncového protokolu na SQL Serveru a pak nastavte distribuovanou skupinu dostupnosti na sekundární roli na SQL Serveru, například v následujícím příkladu:
--Execute on SQL Server
USE MASTER
ALTER availability group [<DAGName>]
SET (role = secondary)
GO
Potom pomocí odkazu spusťte plánované ruční převzetí služeb při selhání ze spravované instance SQL na SQL Server, například v následujícím příkladu:
--Execute on SQL Managed Instance
USE MASTER
ALTER availability group [<DAGName>] FAILOVER
GO
Související obsah
Použití odkazu:
- Příprava prostředí pro odkaz na spravovanou instanci
- Konfigurace propojení mezi SQL Serverem a spravovanou instancí SQL pomocí SSMS
- Konfigurace propojení mezi SQL Serverem a spravovanou instancí SQL pomocí skriptů
- Migrace pomocí odkazu
- Osvědčené postupy pro údržbu odkazu
Další informace o odkazu:
V případě jiných scénářů replikace a migrace zvažte následující: