Sdílet prostřednictvím

Replikace, sledování změn a zachytávání dat – skupiny dostupnosti AlwaysOn

platí pro:SQL Server

Replikace SQL Serveru, zachytávání dat změn (CDC) a sledování změn (CT) jsou podporovány ve skupinách dostupnosti AlwaysOn. Skupiny dostupnosti AlwaysOn pomáhají zajistit vysokou dostupnost a další možnosti obnovení databáze.

Přehled replikace se skupinami dostupnosti

Přesměrování vydavatele

Je-li publikovaná databáze informována o skupinách dostupnosti AlwaysOn, distributor, který poskytuje agentům přístup k databázi publikování, je nakonfigurován s redirected_publishers položkami. Tyto položky přesměrují původně nakonfigurovanou dvojici vydavatele nebo databáze a používají název naslouchacího procesu skupiny dostupnosti pro připojení k databázi vydavatele a publikování. Navázaná připojení prostřednictvím názvu naslouchacího procesu skupiny dostupnosti při převzetí služeb při selhání selžou. Když se agent replikace restartuje po převzetí služeb při selhání, připojení se automaticky přesměruje na nový primární server.

Ve skupině dostupnosti (AG) nemůže být sekundární databáze vydavatelem. Opětovné publikování se podporuje pouze v případech, kdy se transakční replikace kombinuje se skupinami dostupnosti AlwaysOn.

Pokud je publikovaná databáze členem skupiny dostupnosti a vydavatel je přesměrován, musí být přesměrován na název naslouchacího procesu skupiny dostupnosti přidružený ke skupině dostupnosti. Nemusí se přesměrovat na explicitní uzel.

Poznámka:

Po převzetí služeb při selhání sekundární repliky nemůže monitor replikace upravit název instance publikování SQL Serveru a dál zobrazovat informace o replikaci pod názvem původní primární instance SQL Serveru. Po převzetí služeb při selhání se token traceru nedá zadat pomocí monitorování replikace, ale token traceru zadaný v novém vydavateli pomocí jazyka Transact-SQL je viditelný ve službě Replication Monitor.

Obecné změny agentů replikace pro podporu skupin dostupnosti

Tři agenti replikace byli upraveni tak, aby podporovali skupiny dostupnosti AlwaysOn. Agenti Log Reader, Snapshot a Merge byli upraveni tak, aby dotazovali distribuční databázi pro přesměrovaného vydavatele a použili vrácený název naslouchacího procesu skupiny dostupnosti, pokud byl deklarován přesměrovaný vydavatel, aby se připojil k vydavateli databáze.

Ve výchozím nastavení se agenti dotazují distributora, aby určili, jestli byl původní vydavatel přesměrován, před vrácením přesměrovaného hostitele do agenta se ověří vhodnosti aktuálního cíle nebo přesměrování. Toto chování se doporučuje. Pokud k spuštění agenta dochází často, může být režie spojená s uloženou procedurou ověření považována za příliš nákladnou. Do agentů pro čtení protokolů, snímků a slučování se přidal nový přepínač příkazového řádku BypassPublisherValidation. Při použití přepínače se přesměrovaný vydavatel okamžitě vrátí agentu a spuštění uložené procedury ověření se vynechá.

Chyby vrácené z uložené procedury ověření se protokolují v protokolech historie agenta. Tyto chyby se závažností větší nebo rovnou 16 způsobí ukončení agentů. Některé možnosti opakování byly vytvořeny agentům, aby zvládly očekávané odpojení od publikované databáze při převzetí služeb při selhání na novou primární databázi.

Úpravy agenta čtenáře protokolů

Agent čtenáře protokolů má následující změny.

  • Konzistence replikované databáze

    Když je publikovaná databáze členem skupiny dostupnosti, čtenář protokolů ve výchozím nastavení nezpracuje záznamy protokolu, které ještě nebyly posíleny u všech sekundárních replik skupiny dostupnosti. Tím se zajistí, že při převzetí služeb při selhání budou všechny řádky replikované odběrateli přítomny také na nové primární úrovni.

    Pokud má vydavatel pouze dvě repliky dostupnosti (jednu primární a jednu sekundární) a dojde k převzetí služeb při selhání, zůstane původní primární replika mimo provoz, protože čtečka protokolů se nepřesune dál, dokud se všechny sekundární databáze nepřenesou do režimu online nebo dokud se sekundární repliky neodeberou ze skupiny dostupnosti. Čtečka protokolů, která teď běží na sekundární databázi, nepokračuje dál, protože skupina dostupnosti nemůže posílit žádné změny v žádné sekundární databázi. Pokud chcete, aby čtenář protokolů mohl pokračovat dál a stále mít kapacitu zotavení po havárii, odeberte původní primární repliku ze skupiny dostupnosti pomocí skupiny DOSTUPNOSTI ALTER AVAILABITY GROUP <group_name> REMOVE REPLICA. Potom do skupiny dostupnosti přidejte novou sekundární repliku.

  • Příznak trasování 1448

    Příznak trasování 1448 umožňuje čtenáři protokolu replikace přejít vpřed, i když asynchronní sekundární repliky nepotvrdili přijetí změny. I když je tento příznak trasování povolený, čtečka protokolu vždy čeká na synchronní sekundární repliky (můžou se stát asynchronním režimem potvrzení, jak je uvedeno zde, takže čtenář protokolu může pokračovat). Čtečka protokolů nepřekračuje minimální část synchronních sekundárních replik. Tento příznak trasování platí pro instanci SQL Serveru, nejen pro skupinu dostupnosti, databázi dostupnosti nebo instanci čtečky protokolů. Tento příznak trasování musí být v instanci vydavatele povolen. Projeví se okamžitě bez restartování. Dá se aktivovat předem nebo když selže asynchronní sekundární replika.

Uložené procedury podporující skupiny dostupnosti

  • sp_redirect_publisher

    Uložená procedura sp_redirect_publisher slouží k určení přesměrovaného vydavatele pro existující dvojici vydavatele nebo databáze. Pokud databáze vydavatele patří do skupiny dostupnosti, přesměrovaný vydavatel je název naslouchacího procesu skupiny dostupnosti.

  • sp_get_redirected_publisher

    Uložená procedura sp_get_redirected_publisher agenti replikace používají k dotazování distributora, aby zjistili, jestli má dvojice vydavatele nebo databáze definovaného přesměrovaného vydavatele. Tato uložená procedura slouží dvěma účelům. Nejprve umožňuje agentu určit, jestli byl původní vydavatel přesměrován. Za druhé může také zahájit ověřovací uloženou proceduru spuštěnou u distributora (sp_validate_redirected_publisher), která ověřuje vhodnost cílového uzlu přesměrování, aby sloužila jako vydavatel pro pojmenovanou databázi.

    Chcete-li spustit tuto uloženou proceduru, musí být volající buď členem role serveru sysadmin , role databáze db_owner pro distribuční databázi, nebo členem seznamu přístupu publikace pro definovanou publikaci přidruženou k databázi vydavatele.

  • sp_validate_redirected_publisher

    Tato uložená procedura se pokusí ověřit, že aktuální vydavatel může hostovat publikovanou databázi. Je možné volat kdykoli a ověřit, že aktuální hostitel publikované databáze dokáže podporovat replikaci.

  • sp_validate_replicate_hosts_as_publishers

    I když je pro agenty užitečné zajistit, aby aktuální primární server mohl fungovat jako vydavatel replikace pro databázi vydavatele, je potřeba obecnější ověřovací schopnost stanovit platnost celé topologie replikace v databázi skupiny dostupnosti. Uložená procedura sp_validate_replica_hosts_as_publishers je navržená tak, aby tuto potřebu vyplnila.

    Tato uložená procedura se vždy spouští ručně. Volající musí být buď správcem systému u distributora, vlastníka dbowner distribuční databáze, nebo členem Seznamu přístupu k publikaci publikace v databázi vydavatele. Kromě toho musí být přihlášení volajícího platným přihlášením pro všechny hostitele replik dostupnosti a musí mít oprávnění pro databázi dostupnosti přidruženou k databázi vydavatele.

Změna zachytávání dat

Databáze povolené pro zachytávání dat změn (CDC) umožňují používat skupiny dostupnosti AlwaysOn, aby se zajistilo, že databáze zůstane k dispozici v případě selhání, ale že změny tabulek databáze se budou dál monitorovat a ukládat do tabulek změn CDC. Pořadí, ve kterém jsou nakonfigurované skupiny dostupnosti CDC a AlwaysOn, není důležité. Databáze s podporou CDC je možné přidat do skupin dostupnosti AlwaysOn a pro CDC je možné povolit databáze, které jsou členy skupiny dostupnosti. V obou případech se však konfigurace CDC provádí vždy na aktuální nebo zamýšlené primární replice. CDC používá agenta čtenáře protokolů a má stejná omezení, jak je popsáno v části Úpravy agenta čtenáře protokolů výše v tomto článku.

  • Sběr změn pro zachytávání dat změn bez replikace

    Pokud je pro databázi povolená služba CDC, ale replikace není, proces zachycení použitý ke shromažďování změn z protokolu a jejich uložení do tabulek změn CDC běží v hostiteli CDC jako vlastní úloha agenta SQL.

    Aby bylo možné obnovit sběr změn po převzetí služeb při selhání, musí být uložená procedura sp_cdc_add_job spuštěna na nové primární, aby se vytvořila úloha místního zachytávání.

    Následující příklad vytvoří úlohu zachycení.

    EXECUTE sys.sp_cdc_add_job @job_type = 'capture';

  • Sběr změn pro zachytávání dat změn pomocí replikace

    Pokud je pro databázi povolená služba CDC i replikace, bude čtečka protokolů zpracovávat základní soubor tabulek změn CDC. V tomto případě techniky používané replikací k používání skupin dostupnosti AlwaysOn zajišťují, že se změny budou dál získávat z protokolu a po převzetí služeb při selhání se uloží do tabulek změn CDC. Pro CDC v této konfiguraci není potřeba dělat nic dalšího, aby se zajistilo naplnění tabulek změn.

  • Vyčištění zachytávání změn dat

    Aby se zajistilo, že v nové primární databázi dojde k odpovídajícímu vyčištění, měla by se vždy vytvořit místní úloha vyčištění. Následující příklad vytvoří úlohu vyčištění.

    EXECUTE sys.sp_cdc_add_job @job_type = 'cleanup';

    Poznámka:

    Po převzetí služeb při selhání byste měli vytvořit úlohy na nové primární replice. Úlohy CDC spuštěné ve staré primární databázi by měly být zakázány, když se místní databáze stane sekundární databází. Pokud se původní replika znovu stane primární, budete muset znovu použít úlohy CDC na replice této repliky. Pokud chcete úlohy zakázat a povolit, použijte možnost @enabledsp_update_job. Další informace o vytváření úloh CDC najdete v tématu sys.sp_cdc_add_job.

  • Přidání rolí CDC do primární repliky databáze

    Pokud je pro CDC povolená tabulka, je možné přidružit k instanci zachycení roli databáze. Pokud je zadaná role, uživatel, který chce pro přístup ke změnám tabulky použít funkce tabulky CDC, musí mít k tabulce přístup nejen k vybraným sloupcům sledované tabulky, ale musí být také členem pojmenované role. Pokud zadaná role ještě neexistuje, vytvoří se tato role. Když se role databáze automaticky přidají do primární databáze ve skupině dostupnosti, role se také rozšíří do sekundárních databází skupiny dostupnosti.

  • Klientské aplikace, které přistupují ke změně dat CDC a skupin dostupnosti

    Klientské aplikace, které pro přístup ke změně dat tabulky používají funkce s hodnotami tabulky (TVF) nebo propojené servery, potřebují také možnost po převzetí služeb při selhání najít příslušného hostitele CDC. Název naslouchacího procesu skupiny dostupnosti je mechanismus poskytovaný skupinami dostupnosti AlwaysOn, který transparentně umožňuje, aby bylo možné znovu nasměrovat připojení na jiného hostitele. Jakmile je název naslouchacího procesu skupiny dostupnosti přidružený ke skupině dostupnosti, je k dispozici pro použití v připojovacích řetězcích TCP. Dva různé scénáře připojení jsou podporovány prostřednictvím názvu naslouchacího procesu skupiny dostupnosti.

    • Jedním z nich zajistíte, že požadavky na připojení budou vždy směrovány na aktuální primární repliku.
    • Tím zajistíte, že se požadavky na připojení směrují na sekundární repliku jen pro čtení.

    Pokud se používá k vyhledání sekundární repliky jen pro čtení, musí být pro skupinu dostupnosti definován také seznam směrování jen pro čtení. Další informace o směrování přístupu ke čtení sekundárních souborů naleznete v tématu Konfigurace směrování jen pro čtení pro skupinu dostupnosti AlwaysOn.

    Poznámka:

    K vytvoření názvu naslouchacího procesu skupiny dostupnosti a jeho použití klientskými aplikacemi pro přístup k replice databáze skupiny dostupnosti existuje určité zpoždění šíření.

    Pomocí následujícího dotazu určete, jestli je pro skupinu dostupnosti hostující databázi CDC definován název naslouchacího procesu skupiny dostupnosti. Dotaz vrátí název naslouchacího procesu skupiny dostupnosti, pokud byl vytvořen.

    SELECT dns_name
FROM sys.availability_group_listeners AS l
     INNER JOIN sys.availability_databases_cluster AS d
         ON l.group_id = d.group_id
WHERE d.database_name = N'MyCDCDB';

  • Přesměrování načtení dotazu na čitelný sekundární repliku

    V mnoha případech se klientská aplikace vždy chce připojit k aktuální primární replice, ale není to jediný způsob, jak používat skupiny dostupnosti AlwaysOn. Pokud je skupina dostupnosti nakonfigurovaná tak, aby podporovala čitelné sekundární repliky, můžou se data změn shromažďovat také ze sekundárních uzlů.

    Pokud je skupina dostupnosti nakonfigurovaná, ALLOW_CONNECTIONS atribut přidružený k SECONDARY_ROLE slouží k určení typu podporovaného sekundárního přístupu. Pokud je nakonfigurovaná možnost ALL, všechna připojení k sekundární síti jsou povolená, ale pouze ty, které vyžadují přístup jen pro čtení, budou úspěšná. Pokud je nakonfigurovaná jako READ_ONLY, je nutné při vytváření připojení k sekundární databázi zadat záměr jen pro čtení, aby bylo připojení úspěšné. Další informace najdete v tématu Konfigurace přístupu jen pro čtení k sekundární replice skupiny dostupnosti AlwaysOn.

    Následující dotaz se dá použít k určení, jestli je pro připojení k sekundární replice jen pro čtení potřeba záměr jen pro čtení.

    SELECT g.name AS AG,
          replica_server_name,
          secondary_role_allow_connections_desc
FROM sys.availability_replicas AS r
     INNER JOIN sys.availability_groups AS g
          ON r.group_id = g.group_id
WHERE g.name = N'MY_AG_NAME';

    Název naslouchacího procesu skupiny dostupnosti nebo explicitní název uzlu lze použít k vyhledání sekundární repliky. Pokud se použije název naslouchacího procesu skupiny dostupnosti, přístup se směruje na libovolnou vhodnou sekundární repliku.

    Pokud sp_addlinkedserver se používá k vytvoření propojeného serveru pro přístup k sekundárnímu serveru, použije se parametr @datasrc pro název naslouchacího procesu skupiny dostupnosti nebo explicitní název serveru a parametr @provstr slouží k určení záměru jen pro čtení.

    EXECUTE sp_addlinkedserver
    @server = N'linked_svr',
    @srvproduct = N'SqlServer',
    @provider = N'MSOLEDBSQL',
    @datasrc = N'AG_Listener_Name',
    @provstr = N'ApplicationIntent=ReadOnly',
    @catalog = N'MY_DB_NAME';

  • Klientský přístup ke změně dat a přihlášení k doméně CDC

    Obecně platí, že pro přístup klientů ke změně dat umístěných v databázích, které jsou členy skupin dostupnosti, byste měli použít přihlášení k doméně. Aby se zajistil trvalý přístup ke změně dat po převzetí služeb při selhání, uživatel domény potřebuje přístupová oprávnění pro všechny hostitele podporující repliky skupiny dostupnosti. Pokud je uživatel databáze přidaný do databáze v primární replice a uživatel je přidružený k přihlášení k doméně, uživatel databáze se rozšíří do sekundárních databází a bude nadále přidružen k zadanému přihlášení k doméně. Pokud je nový uživatel databáze přidružený k přihlášení k ověřování SQL Serveru, rozšíří se uživatel v sekundárních databázích bez přihlášení. Zatímco přidružené přihlášení k ověřování SQL Serveru se dá použít pro přístup ke změnám dat v primárním umístění, kde byl uživatel databáze původně definovaný, je tento uzel jediným uzlem, kde by byl možný přístup. Přihlášení k ověřování SQL Serveru by nemohlo přistupovat k datům z žádné sekundární databáze ani z nových primárních databází kromě původní databáze, kde byl uživatel databáze definován.

  • Zakázání zachytávání dat změn

    Pokud potřebujete zakázat funkci Change Data Capture (CDC) v databázi, která je součástí skupiny dostupnosti a používáte SQL Server 2016 SP2 nebo novější, nemusíte provádět žádné další kroky pro automatické zkrácení protokolu. Pokud používáte starší verzi než SQL Server 2016 SP2 a zakážete cdC v databázi, která je součástí skupiny dostupnosti, budete muset implementovat jeden z následujících kroků, abyste zabránili blokování zkrácení protokolu po zakázání CDC:

    • Restartujte službu SQL Serveru v každé sekundární instanci repliky.

    • Odeberte databázi ze všech sekundárních instancí replik skupiny dostupnosti a pak ji přidejte zpět do každé instance repliky skupiny dostupnosti pomocí automatického nebo ručního počátečního nastavení.

Sledování změn

Databáze povolená pro sledování změn (CT) může být součástí skupiny dostupnosti. Není potřeba žádná další konfigurace. Klientské aplikace pro sledování změn, které používají funkce tabulky CDC (TVF) pro přístup ke změnám dat, potřebují možnost vyhledat primární repliku po převzetí služeb při selhání. Pokud se klientská aplikace připojuje prostřednictvím názvu naslouchacího procesu skupiny dostupnosti, požadavky na připojení se vždy správně směrují na aktuální primární repliku.

Data sledování změn musí být vždy získána z primární repliky. Při pokusu o přístup ke změně dat ze sekundární repliky dojde k následující chybě:

Msg 22117, Level 16, State 1, Line 1

U databází, které jsou členy sekundární repliky (tj. pro sekundární databáze), není sledování změn podporované. Jako alternativu ke spouštění dotazů sledování změn na primární replice můžete vytvořit snímek databáze skupiny dostupnosti ze sekundární repliky a pak použít k dotazování na data změn. Snímek databáze je statickým zobrazením databáze SQL Serveru (zdrojová databáze), takže data sledování změn v snímku databáze jsou čas, kdy byl snímek pořízen v databázi skupiny dostupnosti ze sekundární repliky.

Poznámka:

Pokud dojde k převzetí služeb při selhání v databázi s povoleným sledováním změn, může doba obnovení v nové primární replice trvat déle, než obvykle, protože sledování změn vyžaduje úplné restartování databáze.

Požadavky, omezení a důležité informace pro použití replikace

Tato část popisuje aspekty nasazení replikace se skupinami dostupnosti AlwaysOn, včetně požadavků, omezení a doporučení.

Požadavky

  • Při použití transakční replikace a databáze publikování je ve skupině dostupnosti, vydavatel i distributor musí spustit alespoň SQL Server 2012 (11.x). Předplatitel může používat nižší úroveň SQL Serveru.

  • Při použití replikace sloučení a publikování databáze je ve skupině dostupnosti:

    • Nabízené předplatné: Vydavatel i distributor musí používat alespoň SQL Server 2012 (11.x).

    • Vyžádané předplatné: Databáze vydavatele, distributora a odběratele musí být minimálně na SQL Serveru 2012 (11.x). Důvodem je to, že agent sloučení na odběrateli musí pochopit, jak může skupina dostupnosti převzít služby při selhání sekundární.

  • Instance publisheru splňují všechny požadavky potřebné k účasti ve skupině dostupnosti. Další informace najdete v tématu Požadavky, omezení a doporučení pro skupiny dostupnosti AlwaysOn.

Restrictions

Podporované kombinace replikace ve skupinách dostupnosti AlwaysOn:

Replication Vydavatel Distributor 1 Subscriber
Transakční Ano

Poznámka: Nezahrnuje podporu obousměrné a reciproční transakční replikace.		 Ano Ano
Peer-to-peer2 Ano Ano 3 Ano
Sloučit Ano Ne Ne
Snímek Ano Ne Ano
Aktualizovatelná předplatná – pro transakční replikaci Ne Ne Ne

1 Distributor databáze není podporována pro použití se zrcadlením databáze.

2 Vyžaduje SQL Server 2019 CU 13 nebo novější.

3 Vyžaduje SQL Server 2019 CU 17 nebo novější.

Úvahy

  • Distribuční databáze není podporovaná pro použití se zrcadlením databáze, ale je podporována u skupin dostupnosti AlwaysOn s výhradou určitých omezení. Další informace naleznete v tématu Konfigurace distribuční skupiny dostupnosti. Konfigurace replikace je svázána s instancí SQL Serveru, kde je distributor nakonfigurován; proto nelze distribuční databázi zrcadlit ani replikovat. Je také možné zajistit vysokou dostupnost distributora pomocí clusteru s podporou převzetí služeb při selhání SQL Serveru. Další informace najdete v tématu Always On instance clusteru s podporou převzetí služeb při selhání (SQL Server).

  • Převzetí služeb při selhání odběratele sekundární databáze, zatímco je podporováno, je ruční postup pro předplatitele sloučení replikace. Postup je v podstatě stejný jako metoda použitá k převzetí služeb při selhání zrcadlené databáze odběratele. Předplatitelé transakční replikace nepotřebují zvláštní zpracování při účasti ve skupinách dostupnosti AlwaysOn. Předplatitelé musí používat SQL Server 2012 (11.x) nebo novější, aby se mohli účastnit skupiny dostupnosti. Další informace najdete v tématu Předplatitelé replikace a skupiny dostupnosti AlwaysOn (SQL Server).

  • Metadata a objekty, které existují mimo databázi, se nerozšírují do sekundárních replik, včetně přihlášení, úloh, propojených serverů. Pokud po převzetí služeb při selhání vyžadujete metadata a objekty v nové primární databázi, musíte je zkopírovat ručně. Další informace najdete v tématu Správa přihlášení pro úlohy pomocí databází ve skupině dostupnosti AlwaysOn.

Distribuované skupiny dostupnosti

Vydavatele nebo distribuční databáze ve skupině dostupnosti nelze konfigurovat jako součást distribuované skupiny dostupnosti. Databáze vydavatele ve skupině dostupnosti a distribuční databáze ve skupině dostupnosti vyžadují koncový bod naslouchacího procesu pro správnou konfiguraci a použití. Není ale možné nakonfigurovat koncový bod naslouchacího procesu pro distribuovanou skupinu dostupnosti.

Replication

Změna zachytávání dat

Sledování změn

Související obsah

  • Last updated on