osvědčené postupy pro Managed Instance propojení – Azure SQL Managed Instance

Applies to:Azure SQL Managed Instance

Tento článek popisuje osvědčené postupy pro použití odkazu Managed Instance k replikaci dat mezi Azure SQL Managed Instance a instancemi SQL Server hostovanými kdekoli. Propojení poskytuje replikaci dat téměř v reálném čase mezi propojenými replikami.

Pravidelné zálohování protokolů

Pokud je SQL Server vaším počátečním primárním serverem, proveďte první zálohu protokolu na SQL Server po dokončení počátečního naplnění, když už databáze není ve stavu Restoring... na Azure SQL Managed Instance. Poté pravidelně zálohujte transakční protokoly SQL Serveru, aby velikost souboru transakčního protokolu byla v pořádku, když je SQL Server v primární roli.

Funkce propojení replikuje data pomocí technologie distribuovaných skupin dostupnosti na základě skupin dostupnosti AlwaysOn. Replikace dat distribuované skupiny dostupnosti je založená na replikaci záznamů transakčního protokolu. Primární SQL Server instance nemůže zkrátit žádné záznamy transakčního protokolu z databáze, dokud nebudou replikovány do databáze na sekundární replice. Pokud problémy s připojením k síti způsobují pomalou nebo blokovanou replikaci záznamů transakčního protokolu, soubor protokolu na primární instanci stále narůstá. Intenzita úloh a rychlost sítě určují rychlost růstu. Pokud je výpadek síťového připojení dlouhodobý a zatížení na primární instanci je vysoké, může soubor protokolu zabrat veškerý dostupný prostor úložiště.

Pravidelné zálohování transakčních protokolů zkracuje transakční protokol a minimalizuje riziko výpadku místa v primární SQL Server instanci kvůli růstu souboru protokolu. Pokud je SQL Managed Instance primárním serverem, není nutná žádná další akce, protože zálohování logu už probíhá automaticky. Pravidelným zálohováním protokolů na primárním serveru SQL se vaše databáze stane odolnější vůči neplánovanému růstu protokolu. Zvažte plánování každodenních úloh zálohování protokolů pomocí úlohy SQL Server Agent.

Pomocí skriptu Transact-SQL (T-SQL) můžete zálohovat soubor protokolu, například ukázku uvedenou v této části. Zástupné symboly v ukázkovém skriptu nahraďte názvem databáze, názvem a cestou záložního souboru a popisem.

K zálohování transakčního protokolu použijte následující ukázkový skript Transact-SQL (T-SQL) na SQL Server:

-- Execute on SQL Server
-- Take log backup
BACKUP LOG [<DatabaseName>]
TO DISK = N'<DiskPathandFileName>'
WITH NOFORMAT, NOINIT,
NAME = N'<Description>', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 1

Pomocí následujícího příkazu Transact-SQL (T-SQL) zkontrolujte místo v protokolu používaném vaší databází v SQL Server:

-- Execute on SQL Server
DBCC SQLPERF(LOGSPACE);

Výstup dotazu vypadá jako v následujícím příkladu ukázkové databáze tpcc:

Snímek obrazovky s výsledky příkazu zobrazující velikost souboru protokolu a využité místo

V tomto příkladu databáze používala 76 % dostupného protokolu s absolutní velikostí souboru protokolu přibližně 27 GB (27 971 MB). Prahové hodnoty pro akci se liší v závislosti na vaší úloze. V předchozím příkladu velikost transakčního protokolu a procento použití protokolu obvykle značí, že byste měli provést zálohu transakčního protokolu, abyste zkrátili soubor protokolu a uvolnili nějaké místo, nebo byste měli provádět častější zálohování protokolů. Může to také značit, že truncace transakčního protokolu je blokována otevřenými transakcemi. Další informace o řešení potíží s transakčním protokolem v SQL Server najdete v tématu Řešení úplného transakčního protokolu (SQL Server Chyba 9002). Další informace o řešení potíží s transakčním protokolem v Azure SQL Managed Instance najdete v tématu Řešení chyb transakčního protokolu s Azure SQL Managed Instance.

Poznámka:

Když se účastníte propojení, SQL Managed Instance provádí automatizované plné zálohy a zálohy transakčních protokolů, bez ohledu na to, jestli jde o primární repliku. Rozdílové zálohy se neprovádí, což může vést k delší době obnovy.

Sladění výkonové kapacity mezi replikami

Pokud použijete funkci propojení, slaďte kapacitu výkonu mezi SQL Serverem a SQL Managed Instance. Tato shoda pomáhá vyhnout se problémům s výkonem, pokud sekundární replika nemůže držet krok s replikací z primární repliky nebo po převzetí služeb při selhání. Kapacita výkonu zahrnuje jádra procesoru (nebo virtuální jádra v Azure), paměť a propustnost vstupně-výstupních operací.

Výkon replikace můžete monitorovat kontrolou velikosti fronty opakování na sekundární replice. Velikost fronty přehrání ukazuje počet záznamů protokolu, které čekají na přehrání na sekundární replice. Konzistentně vysoká velikost fronty zápisů ukazuje, že sekundární replika nemůže držet krok s primární replikou. Velikost fronty znovu můžete zkontrolovat následujícími způsoby:

Hodnota redo_queue_size v dynamickém zobrazení správy sys.dm_hadr_database_replica_states na primární replice.
Hodnota InstanceRedoLagReplicationSeconds v Get-AzSqlInstanceLink na primární replice.

Pokud je velikost fronty opětovného zpracování konzistentně vysoká, zvažte zvýšení prostředků na sekundární replice.

Monitorování prodlevy replikace

Monitorování prodlevy replikace vám pomůže určit rychlost, s jakou se sekundární replika synchronizuje s primární replikou. Velká nesrovnalost značí, že sekundární replika má potíže udržet krok s primární replikou, což je obvykle způsobené pomalou propustností sítě v propojení mezi dvěma instancemi, neshodou přidělení prostředků mezi těmito dvěma replikami nebo nadměrným vysokým zatížením primární repliky.

Monitorování prodlevy replikace je zvlášť důležité při provádění plánovaného převzetí služeb při selhání, které vyžaduje, aby sekundární replika byla plně synchronizovaná s primární replikou před spuštěním převzetí služeb při selhání. Pokud je prodleva replikace vysoká, přepnutí při selhání může trvat déle a v některých případech může dokonce selhat.

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

Rotace certifikátu

Možná budete muset certifikát použitý k zabezpečení koncového bodu zrcadlení databáze na SQL Server ručně otočit. Vzhledem k tomu, že služba spravuje a automaticky obměňuje certifikát použitý k zabezpečení koncového bodu zrcadlení databáze na SQL Managed Instance, nemusíte ho ručně otáčet.

SQL Server

Platnost certifikátu, který používáte k zabezpečení koncového bodu zrcadlení databáze SQL Server, může vypršet. Pokud platnost certifikátu vyprší, může vést ke snížení výkonu propojení. Pokud chcete tomuto problému zabránit, otočte certifikát před vypršením jeho platnosti.

Pomocí následujícího příkazu Transact-SQL (T-SQL) zkontrolujte datum vypršení platnosti aktuálního certifikátu:

-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK'

Pokud platnost vašeho certifikátu brzy vyprší nebo už vypršela, vytvořte nový certifikát a změňte existující koncový bod tak, aby nahradil aktuální certifikát.

Jakmile nakonfigurujete koncový bod tak, aby používal nový certifikát, můžete certifikát s vypršenou platností vypustit .

SQL Managed Instance

Certifikát koncového bodu zrcadlení databáze na SQL Managed Instance se pravidelně rotuje. Na SQL Managed Instance nemusíte monitorovat datum vypršení platnosti certifikátu koncového bodu zrcadlení databáze, pokud můžete úspěšně ověřit řetězec certifikátů na SQL Server.

Ověření řetězu certifikátů na SQL Server

Poznámka:

Pravidelně ověřte řetěz certifikátů pro existující propojení nebo vyřešte problémy s degradovaným propojením. Pokud konfigurujete nový odkaz nebo jste nedávno dokončili kroky uvedené v částech Naimportujte veřejný klíč certifikátu z SQL Managed Instance a importujte ho do SQL Server a Importujte klíče kořenové certifikační autority Azure důvěryhodných kořenových certifikačních autorit do SQL Server přeskočte tuto část.

Problémy s řetězem certifikátů můžou odkaz snížit. Chcete-li zabránit tomuto problému, regularálně ověřte řetěz certifikátů na SQL Server.

Následující scénáře můžou způsobovat problémy s řetězem certifikátů na SQL Server:

Plánovaná obměně certifikátů na SQL Managed Instance
Neúmyslné nebo náhodné změny certifikátů na SQL Server, jako je například vyřazení nebo změna certifikátu použitého k zabezpečení koncového bodu zrcadlení databáze.

Nejprve určete certificate_id importovaného certifikátu koncového bodu MI nahrazením hodnoty <ManagedInstanceFQDN> a spuštěním následujícího dotazu na SQL Server:

-- Run on SQL Server 
USE master 
SELECT name, subject, certificate_id, start_date, expiry_date 
FROM sys.certificates 
WHERE issuer_name LIKE '%Microsoft Corporation%' AND name = '<ManagedInstanceFQDN>' 
GO

Potom ověřte certifikát nahrazením hodnoty <certificate_id> z výsledku předchozího dotazu a spuštěním následujícího dotazu na SQL Server:

-- Run on SQL Server 
USE master
EXEC sp_validate_certificate_ca_chain <certificate_id> 
GO

Odpověď Commands completed successfully. Completion time: ... značí, že certifikát koncového bodu MI byl úspěšně ověřen.

Důležité

Uložená procedura sp_validate_certificate_ca_chain spoléhá na hostitelské služby operačního systému k ověření certifikátu, což může zahrnovat online kontrolu odvolání certifikátu. Pokud hostitelský operační systém není nakonfigurovaný pro přístup k internetu, spuštění selže, i když je řetěz certifikátů platný.

Pokud dojde k chybě, nejspolehlivějším řešením je obnovení řetězu certifikátů tak, že nejprve odeberete všechny certifikáty vytvořené v oddílech Získejte veřejný klíč certifikátu z SQL Managed Instance a importujte jej do SQL Server a Importujte klíče Azure-důvěryhodných kořenových certifikačních autorit do SQL Server, a poté je znovu naimportujete.

Přidání příznaků trasování po spuštění

V SQL Server existují dva příznaky trasování (-T1800 a -T9567), které při přidání jako spouštěcí parametry můžou optimalizovat výkon replikace dat prostřednictvím propojení. Další informace najdete v návodu Povolení trasovacích příznaků po spuštění.

Použití synchronního potvrzení s opatrností

Výchozí režim potvrzení odkazu je asynchronní. I když je možné změnit režim potvrzení na synchronní, nedoporučuje se a není nutné zabezpečit před potenciální ztrátou dat.

Během plánovaného svázaného převzetí služeb při selhání replikace dočasně přepíná do režimu synchronního potvrzování, dokud se převzetí služeb při selhání nedokončí. Po přepnutí při selhání se režim potvrzení přepne zpět na asynchronní, i když byl před tím explicitně nastaven na synchronní.

Použití synchronního režimu potvrzení pro propojení může mít vliv na výkon primární repliky, zejména pokud mezi replikami existuje vysoká latence sítě. V synchronním režimu potvrzení musí transakce na primární replice počkat na potvrzení, že záznamy transakčního protokolu jsou posíleny na sekundární replice, než je možné transakce potvrdit na primárním serveru. Tato doba čekání se zvyšuje s vyšší latencí sítě, což může vést ke zvýšení doby odezvy transakcí a snížení propustnosti primární repliky.

Použití odkazu:

Další informace o odkazu:

Přehled propojení Managed Instance
Obnova po havárii s odkazem na instanci Managed Instance
osvědčené postupy pro údržbu odkazu

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