Seriál o replikaci na SQL Serveru 2012 – II. díl

V prvním díle seriálu o SQL replikaci jsme si popsali snapshot replikaci a možnosti jejího nastavení na SQL Serveru 2012. V dnešním díle se budeme zabývat transakční replikací. Transakční replikace začíná zpravidla pomocí snapshotu z publikovaných dat. Následně každá změna v datech nebo schématu na publisher serveru je synchronizována na subscriber v reálném čase a ve správném pořadí v jakém tyto změny probíhaly na publisher serveru (tím je udržena transakční konzistentnost mezi publisher a subscriber servery).

Kdy tedy použít transakční replikaci? Nejčastěji ji používáme v server-to-server scénářích kdy

• Chceme synchronizovat změny v témeř reálném čase (dosáhnout nízkého času mezi provedením změny na publisher serveru a její propagací na subscriber)
• Máme dostupnou spolehlivou a rychlou konektivitu mezi servery
• Na publisher serveru je frekvence změny v datech velmi vysoká
• Jedná se o heterogení prostředí, např. Oracle servery
• Potřebujeme synchronizovat změny na datech inkrementálně (změní-li se hodnota několikrát, potřebujeme např. při každé změně spustit trigger)

Edice a dostupnost funkcí

Transakční replikace je podporována na všech běžných edicích SQL Serveru 2012, ale u edicí Web a Express je transakční replikace podporována jen pro roli subscriber. Nemohou tedy sloužit jako zdroj dat v serverové roli publisher a také distributor. Mj. je z tabulky patrné, že nejvíce funkcí je dostupných na edici Enterprise, která jako jediná nabízí Peer2Peer transakční replikace a Oracle Publishing. Nicméně Oracle publishing je označen jako deprecated feature, tedy nebude v dalších vydáních dostupný a peer2peer replikace je nahraditelná jinými možnostmi pro vysokou dostupnost a škálovatelnost serveru.

Transakční replikace nám nabízí více možností při tvorbě publikací. Běžná publikace je vytvořená jako read-only, ale při práci s transakční replikací máme možnost zvolit i další režimy, které dovolují měnit data i na subscriber serveru a synchronizovat změny zpět pomocí protokolu two-phase commit (2PC). Tato varianta replikace je dostupná pouze do verze 2012, ve verzi 2014 (aktuálně CTP2) již není k dispozici.

Konfigurace transakční replikace

Pro vytvoření publikací a nastavení transakční replikace můžeme použít SQL Management Studio, nebo přímo T-SQL a celou replikaci naskriptovat pomocí několika uložených procedur. Možnosti pro výběr částí databáze, které budou replikovány, jsou stejné jako u snapshot replikace.

Při výběrů jednotlivých artiklů máme možnost i detailně vybrat další objekty, které jsou asociovány s tabulkou, pohledem a jinými artikly a konfigurovat, jestli další navázané objekty mají být také replikovány. Mezi tyto objekty patří například indexy, statistiky, individuální oprávnění, constraints a další nastavení.

Následně je možné zvolit i filtry, kterými můžeme vybrat jednotlivé řádky tabulek nebo pohledů pro replikaci, a samozřejmě na předchozím dialogu i jednotlivé replikované sloupce. Replikace nemusí nutně přenášet celou tabulku, ale pouze její část.

Replikační agenti

Při transakční replikaci hrají klíčovou úlohu tři agenti – log reader agent, queue reader agent a snapshot agent. Snapshot agent je využit na začátku replikace pro vytvoření prvotního snapshotu. Při konfiguraci transakční replikace je možné nechat systém automaticky vygenerovat snapshot ihned při konfiguraci nebo naplánovat jeho tvorbu na pozdější dobu. Při tvorbě snapshotu je možné měnit data v databázi a tyto změny budou reflektovány na subscriber server pomocí agenta log reader. Během konfigurace replikace je nutné nastavit zabezpečení pro agenty snapshot a log reader. U obou agentů je nutné nastavit účet, pod kterým samotný agent poběží a také účet, pod kterým se tito agenti připojojují na publisher server (tento účet může být shodný s účtem jednotlivých agentů, ale je možné je oddělit).

V nastavení jednotlivých artiklů pro replikaci je i volba pro přenos snapshotu pomocí FTP prokolu. Je nutné nastavit FTP server a ověřování (login, heslo, remote path atd) pro uložení snapshotu na FTP server.

Log reader agent sleduje transakční log na publikační databázi a hlídá, jestli neproběhly změny, které je nutné replikovat na subscriber server. Všechny takové změny přenáší do distribuční databáze, ze které si je vyzvedne distribuční agent. Log reader agent je nastaven jako plánovaná úloha v SQL agentovi a je zkonfigurován tak, aby běžel neustále od startu SQL Server Agenta.

Queue reader agent je používán pouze u transakční replikace pro modifikaci dat zpět na publisher server. Queue reader agent spravuje frontu na subscriber serveru a přeposílá zprávy zpět na publikovanou databázi. Queue reader agent je spuštěn na distribučním serveru pouze jednou a spravuje všechny přidružené publisher servery a jejich jednotlivé publikace.

Závěr

V dnešním díle jsme si podrobněji představili transakční replikaci a v dalším díle se podíváme na možnosti peer to peer transakční replikace a merge replikace. Transakční replikace pro svou konfiguraci potřebuje prvotní snapshot a následně synchronizuje data pomocí transakčního logu (změny v logu hlídá log reader agent). Nejčastěji tuto replikaci používáme, chceme-li dosáhnout synchronizace mezi servery v téměř reálném čase.

Autor: Marek Chmel, MVP

Články ze série Microsoft TechNet nevytváří redakce Živě.cz, ale partneři programu Microsoft TechNet. Jsou publikovány v rámci mediálního partnerství Živě.cz a společnosti Microsoft.