reklama

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í.

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.

 

Enteprise

Business Intelligence

Standard

Web

Express

Snapshot

Ano

Ano

Ano

Ano

Ano

Transakční

Ano

Ano

Ano

Ano

Ano

Merge

Ano

Ano

Ano

Ano

Ano

Oracle publishing

Ano

Ne

Ne

Ne

Ne

Heterogenní subscriber

Ano

Ano

Ne

Ne

Ne

Peer to Peer

Ano

Ne

Ne

Ne

Ne

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.

Klepněte pro větší obrázek

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í.

Klepněte pro větší obrázek

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).

Klepněte pro větší obrázek

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.

Klepněte pro větší obrázek

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.

Témata článku: Subscriber, Peer, Trigger, Phase

Nejnovější komentáře

Můj názor
reklama
Určitě si přečtěte

UPC překopli páteřní kabel. V Brně i druhý den nejede internet ani kabelovka

UPC překopli páteřní kabel. V Brně i druhý den nejede internet ani kabelovka

** V Brně byl velký výpadek služeb UPC ** Důvodem je překopnutý páteřní kabel ** V některých lokalitách služby stále nefungují

5.  12.  2016 | Jakub Čížek | 100

ASUS ZenBook 3 se začal prodávat v Česku. Je ve všem lepší než MacBook, ale bude to stačit?

ASUS ZenBook 3 se začal prodávat v Česku. Je ve všem lepší než MacBook, ale bude to stačit?

** Novinka od Asusu míří přímo proti MacBooku od Applu ** Nabídne daleko více výkonu za stejné peníze

2.  12.  2016 | David Polesný | 144

17 expertek Microsoftu předpovědělo rok 2027. Splní se alespoň něco?

17 expertek Microsoftu předpovědělo rok 2027. Splní se alespoň něco?

** Zmizí klasické vyhledávače ** Budeme programovat buňky ** Kvantové počítače překonají šifry

Včera | Jakub Čížek | 34


reklama