Transakční replikace se službou Azure SQL Managed Instance

Platí pro:Azure SQL Managed Instance

Transakční replikace je funkce služby Azure SQL Managed Instance a SQL Serveru, která umožňuje replikovat data z tabulky ve spravované instanci Azure SQL nebo instanci SQL Serveru do tabulek umístěných ve vzdálených databázích. Tato funkce umožňuje synchronizovat více tabulek v různých databázích.

Přehled

Transakční replikaci můžete použít k nasdílení změn provedených ve spravované instanci Azure SQL do:

  • Databáze SQL Serveru (místní nebo na virtuálním počítači Azure)
  • Databáze ve službě Azure SQL Database
  • Instanční databáze ve službě Azure SQL Managed Instance

Poznámka:

Pokud chcete používat všechny funkce služby Azure SQL Managed Instance, musíte použít nejnovější verze aplikace SQL Server Management Studio (SSMS) a SQL Server Data Tools (SSDT).

Komponenty

Klíčové komponenty v transakční replikaci jsou Vydavatel, Distributor a Odběratel, jak je znázorněno na následujícím obrázku:

Diagram of replication with Azure SQL.

Role Azure SQL Database Azure SQL Managed Instance
Vydavatel No Ano
Distributor No Ano
Odběratel vyžádané replikace No Ano
Odběratel nabízených oznámení Ano Yes

Publisher publikuje změny provedené u některých tabulek (článků) odesláním aktualizací distributoru. Vydavatelem může být spravovaná instance Azure SQL nebo instance SQL Serveru.

Distributor shromažďuje změny v článcích od vydavatele a distribuuje je odběratelům. Distributorem může být spravovaná instance Azure SQL nebo instance SQL Serveru (pokud je jakákoli verze rovna nebo vyšší než verze Publisheru).

Odběratel obdrží změny provedené v Publisheru. Instance SQL Serveru a spravovaná instance Azure SQL můžou být nabízení i vyžádaní předplatitelé, i když se předplatné vyžádané replikace nepodporuje, pokud je distributor spravovanou instancí Azure SQL a odběratel není. Databáze ve službě Azure SQL Database může být jenom odběratelem nabízených oznámení.

Spravovaná instance Azure SQL může podporovat odběratele z následujících verzí SQL Serveru:

Poznámka:

U jiných verzí SQL Serveru, které nepodporují publikování do objektů v Azure, můžete pomocí metody opětovného publikování dat přesunout data do novějších verzí SQL Serveru.

Pokus o konfiguraci replikace pomocí starší verze může mít za následek chybu MSSQL_REPL20084 (proces se nemohl připojit k odběrateli) a MSSQL_REPL40532 (Nelze otevřít název> serveru <požadovaný pro přihlášení. Přihlášení se nezdařilo).

Typy replikace

Existují různé typy replikace:

Replikace Azure SQL Database Spravovaná instance Azure SQL
Standardní transakční Ano (pouze jako odběratel) Yes
Snímková Ano (pouze jako odběratel) Yes
Slučovací replikace No Ne
Peer-to-peer No No
Obousměrná No Yes
Aktualizovatelná předplatná No Ne

Matice možností podpory

Matice podpory transakční replikace pro spravovanou instanci Azure SQL je stejná jako matice podpory transakční replikace pro SQL Server.

Vydavatel Distributor Odběratel
SQL Server 2022 SQL Server 2022 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2019 SQL Server 2022
SQL Server 2019
SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2017 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2016 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2014 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008
SQL Server 2012 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008
SQL Server 2008 R2
SQL Server 2008
SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008

Vhodné použití služby

Transakční replikace je užitečná v následujících situacích:

  • Publikujte změny provedené v jedné nebo více tabulkách v databázi a distribuujte je do jedné nebo mnoha databází v instanci SQL Serveru nebo ve službě Azure SQL Database, která se přihlásila k odběru změn.
  • Udržujte několik distribuovaných databází v synchronizovaném stavu.
  • Migrace databází z jedné instance SQL Serveru nebo azure SQL Managed Instance do jiné databáze průběžným publikováním změn

Porovnání Synchronizace dat s transakční replikací

Kategorie Synchronizace dat Transakční replikace
Výhody – Podpora aktivní-aktivní
– Obousměrné mezi místním prostředím a službou Azure SQL Database
- Nižší latence
– Transakční konzistence
– Opakované použití stávající topologie po migraci
Nevýhody – Bez transakční konzistence
- Vyšší dopad na výkon
– Nejde publikovat ze služby Azure SQL Database
- Vysoké náklady na údržbu

Běžné konfigurace

Obecně platí, že vydavatel a distributor musí být buď v cloudu, nebo místně. Podporují se tyto konfigurace:

Vydavatel s místním distributorem ve službě SQL Managed Instance

Single instance as Publisher and Distributor.

Vydavatel a distributor jsou nakonfigurované v rámci jedné spravované instance SQL a distribuují změny do jiné spravované instance SQL, služby SQL Database nebo instance SQL Serveru.

Vydavatel se vzdáleným distributorem ve službě SQL Managed Instance

V této konfiguraci jedna spravovaná instance SQL publikuje změny distributora umístěného v jiné spravované instanci SQL, která může obsluhovat mnoho zdrojových spravovaných instancí SQL a distribuovat změny do jednoho nebo mnoha cílů ve službě Azure SQL Database, Azure SQL Managed Instance nebo SQL Serveru.

Separate instances for Publisher and Distributor.

Vydavatel a distributor jsou nakonfigurované ve dvou spravovaných instancích. U této konfigurace existují určitá omezení:

  • Obě spravované instance jsou ve stejné virtuální síti.
  • Obě spravované instance jsou ve stejném umístění.

Místní vydavatel nebo distributor se vzdáleným předplatitelem

Azure SQL Database as subscriber.

V této konfiguraci je databáze ve službě Azure SQL Database nebo Azure SQL Managed Instance odběratelem. Tato konfigurace podporuje migraci z místního prostředí do Azure. Pokud je předplatitelem databáze ve službě Azure SQL Database, musí být v režimu nabízení.

Požadavky

  • Pro připojení mezi účastníky replikace použijte ověřování SQL.
  • Použijte sdílenou složku účtu úložiště Azure pro pracovní adresář používaný replikací.
  • Otevřete odchozí port TCP 445 v pravidlech zabezpečení podsítě pro přístup ke sdílené složce Azure.
  • Pokud je spravovaná instance SQL vydavatelem nebo distributorem, otevřete odchozí port TCP 1433 a odběratel není. Možná budete také muset změnit pravidlo odchozího zabezpečení NSG spravované instance SQL pro allow_linkedserver_outbound značku cílové služby portu 1433 z virtualnetwork na internet.
  • Umístěte vydavatele i distributora do cloudu nebo do místního prostředí.
  • Pokud se virtuální sítě liší, nakonfigurujte partnerský vztah VPN mezi virtuálními sítěmi účastníků replikace.

Poznámka:

K chybě 53 může dojít při připojování k souboru azure Storage, pokud je port 445 odchozí skupiny zabezpečení sítě (NSG) blokovaný, pokud je distributor databází azure SQL Managed Instance a předplatitel je místní. Pokud chcete tento problém vyřešit, aktualizujte skupinu zabezpečení sítě virtuální sítě.

Omezení

Transakční replikace má určitá omezení specifická pro službu Azure SQL Managed Instance. Další informace o těchto omezeních najdete v této části.

Soubory snímků se neodstraní z účtu úložiště Azure

Spravovaná instance Azure SQL používá uživatelem nakonfigurovaný účet služby Azure Storage pro soubory snímků používané pro transakční replikaci. Na rozdíl od SQL Serveru v místním prostředí služba Azure SQL Managed Instance neodstraní snímkové soubory z účtu úložiště Azure. Jakmile už soubory nepotřebujete, měli byste je odstranit. Můžete to provést prostřednictvím rozhraní Azure Storage na webu Azure Portal, Průzkumník služby Microsoft Azure Storage nebo prostřednictvím klientů příkazového řádku (Azure PowerShell nebo CLI) nebo rozhraní REST API služby Azure Storage Management.

Tady je příklad, jak můžete odstranit soubor a jak můžete odstranit prázdnou složku.

az storage file delete-batch --source <file_path> --account-key <account_key> --account-name <account_name>
az storage directory delete --name <directory_name> --share-name <share_name> --account-key <account_key> --account-name <account_name>

Počet distribučních agentů spuštěných nepřetržitě

Počet distribučních agentů nakonfigurovaných tak, aby běžel nepřetržitě, je omezený na 30 ve službě Azure SQL Managed Instance. Pokud chcete mít více distribučních agentů, musí běžet na vyžádání nebo s definovaným plánem. Plán je možné definovat s denní frekvencí a výskytem každých 10 sekund (nebo více), takže i když není nepřetržitý, stále můžete mít distributora, který zavádí latenci, která je jen několik sekund. Pokud potřebujete velký počet distributorů, doporučuje se použít naplánovanou a ne nepřetržitou konfiguraci.

Se skupinami převzetí služeb při selhání

Použití transakční replikace s instancemi, které jsou ve skupině převzetí služeb při selhání, je podporováno. Pokud ale nakonfigurujete replikaci před přidáním spravované instance SQL do skupiny převzetí služeb při selhání, replikace se pozastaví, jakmile začnete vytvářet skupinu převzetí služeb při selhání, a monitor replikace zobrazí stav Replicated transactions are waiting for the next log backup or for mirroring partner to catch up. Replikace se obnoví po úspěšném vytvoření skupiny převzetí služeb při selhání.

Pokud je spravovaná instance SQL vydavatele nebo distributora ve skupině převzetí služeb při selhání, musí správce spravované instance SQL vyčistit všechny publikace na staré primární instanci a po převzetí služeb při selhání je znovu nakonfigurovat na nové primární instanci. V tomto scénáři jsou potřeba následující aktivity:

  1. Pokud existují nějaké úlohy replikace, zastavte všechny úlohy replikace spuštěné v databázi.

  2. Odstraňte metadata předplatného od vydavatele spuštěním následujícího skriptu v databázi vydavatele. <name of publication> Nahraďte hodnoty:<name of subscriber>

    EXEC sp_dropsubscription @publication = '<name of publication>',
        @article = 'all',
        @subscriber = '<name of subscriber>'
    
  3. Odstraňte metadata předplatného od odběratele. Spusťte následující skript pro databázi předplatného spravované instance SQL odběratele. <full DNS of publisher> Nahraďte hodnotu. Příklad: example.ac2d23028af5.database.windows.net

    EXEC sp_subscription_cleanup
       @publisher = N'<full DNS of publisher>',
       @publisher_db = N'<publisher database>',
       @publication = N'<name of publication>';
    
  4. Vynuceně zahoďte všechny objekty replikace od vydavatele spuštěním následujícího skriptu v publikované databázi:

    EXEC sp_removedbreplication;
    
  5. Vynuceně zahoďte starého distributora z původní primární spravované instance SQL (pokud se při selhání vrátíte na původní primární instanci, která používala distributora). Spusťte následující skript v master databázi ve staré instanci spravované službou SQL distributora:

    EXEC sp_dropdistributor 1, 1;
    

Pokud je spravovaná instance SQL odběratele ve skupině převzetí služeb při selhání, měla by být publikace nakonfigurovaná tak, aby se připojila ke koncovému bodu naslouchacího procesu skupiny převzetí služeb při selhání pro spravovanou instanci SQL odběratele. V případě převzetí služeb při selhání závisí následná akce správce spravované instance SQL na typu převzetí služeb při selhání, ke kterému došlo:

  • U převzetí služeb při selhání bez ztráty dat bude replikace pokračovat v práci po převzetí služeb při selhání.
  • U převzetí služeb při selhání se ztrátou dat funguje i replikace. Znovu replikuje ztracené změny.
  • V případě převzetí služeb při selhání se ztrátou dat je ale ztráta dat mimo dobu uchovávání distribuční databáze, musí správce spravované instance SQL znovu inicializovat databázi předplatného.

Řešení běžných potíží

Transakční protokol a transakční replikace

Za obvyklých okolností se protokol transkace používá k zaznamenávání změn dat v databázi. Změny se zaznamenávají v transakčním protokolu a tím se zvýší spotřeba úložiště protokolů. Existuje také automatický proces, který umožňuje bezpečné zkrácení transakčního protokolu a tento proces snižuje využitý prostor úložiště pro protokol. Při publikování pro transakční replikaci je nakonfigurováno zkrácení transakčního protokolu je zabráněno, dokud se změny v protokolu nezpracují úlohou čtenáře protokolu. Za některých okolností je zpracování transakčního protokolu efektivně blokováno a tento stav může vést k naplnění celého úložiště vyhrazeného pro transakční protokol. Pokud neexistuje volné místo pro transakční protokol a není k dispozici žádné místo pro růst transakčního protokolu, máme úplný transakční protokol. V tomto stavu už databáze nemůže zpracovat žádnou úlohu zápisu a efektivně se stane databází jen pro čtení.

Zakázaný agent čtenáře protokolů

Publikování transakční replikace je někdy nakonfigurováno pro databázi, ale agent čtenáře protokolů není nakonfigurován ke spuštění. V takovém případě se změny hromadí v transakčním protokolu a nezpracovávají se. To vede k neustálému růstu transakčního protokolu a nakonec k úplnému transkačnímu protokolu. Uživatel by se měl ujistit, že úloha čtenáře protokolu existuje a je aktivní. Alternativou je zakázat transakční replikaci, pokud ji nepotřebujete.

Vypršení časových limitů dotazů agenta čtenáře protokolů

Úloha čtečky protokolů někdy nemůže efektivně postupovat kvůli opakovaným vypršením časových limitů dotazů. Způsob, jak opravit časové limity dotazů, je zvýšit nastavení časového limitu dotazu pro úlohu agenta čtenáře protokolu.

Zvýšení časového limitu dotazu pro úlohu čtenáře protokolů je možné provést pomocí aplikace SSMS. V Průzkumníku objektů v části Agent SQL Serveru vyhledejte úlohu, kterou chcete upravit. Nejprve ji zastavte a otevřete její vlastnosti. Najděte step 2 a upravte ho. Připojte hodnotu příkazu pomocí -QueryTimeout <timeout_in_seconds>příkazu . Pro hodnotu časového limitu dotazu zkuste 21600 nebo vyšší. Nakonec znovu spusťte úlohu.

Velikost úložiště protokolů dosáhla maximálního limitu 2 TB

Když velikost úložiště transakčních protokolů dosáhne maximálního limitu, což je 2 TB, protokol fyzicky nemůže zvětšit víc. V tomto případě jediným dostupným zmírněním je označení všech transakcí, které se mají replikovat jako zpracované, aby bylo možné zkrátit transakční protokol. To znamená, že zbývající transakce v protokolu nebudou replikovány a je nutné znovu inicializovat replikaci.

Poznámka:

Po zmírnění rizik budete muset znovu inicializovat replikaci, což znamená, že replikuje celou sadu dat znovu. Jedná se o velikost operace dat a může být dlouhotrvající v závislosti na množství dat, která by se měla replikovat.

Pokud chcete provést zmírnění rizik, musíte nejprve zastavit agenta čtenáře protokolu na distributoru. Pak byste měli spustit uloženou proceduru sp_repldone s příznakem nastaveným reset na 1 databázi vydavatele, aby bylo možné zkrátit transakční protokol. Tento příkaz by měl vypadat takto EXEC sp_repldone @xactid = NULL, @xact_seqno = NULL, @numtrans = 0, @time = 0, @reset = 1. Potom budete muset replikaci znovu inicializovat.

Další kroky

Další informace o konfiguraci transakční replikace najdete v následujících kurzech:

Viz také