Transakční replikace serveru SQL je jednou z nejběžněji používaných replikačních technik používaných ke kopírování nebo distribuci dat mezi více cíli. V předchozím článku jsme diskutovali o replikaci serveru SQL, typech replikace a základních interních informacích o tom, jak funguje transakční replikace. Nyní se ponoříme do Advanced Internals, jak funguje SQL Server Transakční replikace.
Architektura transakční replikace
Než začneme, doporučuji vám osvěžit si znalosti mým předchozím článkem zde.
Začněme tím, že se podíváme na SQL Server Transakční replikační architekturu zobrazenou níže z dokumentace společnosti Microsoft.
V Databázi vydavatelů , vytvořte Publikaci obsahující seznam článků (Tabulky , Zobrazení , atd.), které musíte replikovat na Odběratele databáze. Jakmile je u článků povolena replikace, veškeré změny, ke kterým dojde v těchto článcích, budou označeny pro replikaci v databázi Transakční protokoly vydavatele.
Transakční replikaci serveru SQL lze inicializovat z Vydavatele distributorovi a poté na Odběratele databázi prostřednictvím Agenta snímku nebo Plná Zálohy . Snapshot Agent může provést Inicializaci prostřednictvím Průvodce konfigurací replikace . Úplná záloha je podporována pouze prostřednictvím příkazů T-SQL.
Agent čtečky protokolů prohledá transakční protokol databáze Publisher, aby zjistil sledované změny označené pro replikaci. Ignoruje ostatní změny zaznamenané v protokolech transakcí a zkopíruje změny dat z protokolu transakcí do databáze distribuce.
Distribuční databáze může být buď v aplikaci Publisher nebo Subscriber, nebo může být v jiné nezávislé instanci SQL Server. Všimněte si následujících věcí:
- Agent Log Reader běží nepřetržitě z distribučního serveru a hledá nové příkazy označené pro replikaci. Pokud však nechcete běžet nepřetržitě a chcete místo toho běžet podle plánu, můžeme změnit úlohu SQL agenta Log Reader Agent, která bude vytvořena.
- Agent Log Reader vyzvedne všechny záznamy, které jsou označeny pro replikaci, z dávek Transakčního protokolu a odešle je do distribuční databáze.
- Agent Log Reader sbírá pouze potvrzené transakce z Transakčního protokolu databáze vydavatele. Jakékoli dlouhotrvající dotazy na databázi Publisher tedy mohou přímo ovlivnit replikaci, protože čeká na dokončení aktivní transakce.
Distribuční agent vyzvedne všechny nedistribuované nové příkazy z distribuční databáze a aplikuje je na předplatitelskou databázi buď pomocí Push nebo Vytáhnout Mechanismus .
- Přihlášení k odběru – Distributor přebírá vlastnictví za použití změn z distribuční databáze na předplatitele.
- Převzít předplatné – Předplatitel databáze přebírá vlastnictví k načítání změn z distribuční databáze k odběrateli.
Jakmile budou záznamy úspěšně distribuovány z distribuce do databáze odběratelů, budou označeny jako Distribuované a také označeno pro smazání z distribuční databáze .
Jednou z úloh údržby replikace klíčů je Vyčištění distribuce :Úloha distribuce se spouští každých 10 minut a odstraňuje distribuované záznamy z databáze distribuce, aby byla velikost databáze distribuce pod kontrolou.
Proto je naším cílem pro aktuální článek prozkoumat následující témata:
- Distribuční databáze
- Replikační agenti
- Agent snímku
- Agent čtečky protokolů
- Distribuční agent
- Profily replikačních agentů
- Úlohy údržby replikace
- Latence replikace a sledovací tokeny
- Nástroj TableDiff
- Výstrahy SQL Server Agent
SQL Server Distribuční databáze
Distribuční databáze je systémová databáze vytvořená při konfiguraci Replikace. Je srdcem replikace, protože většina procesu se vyčerpá z distribuční databáze.
Vzhledem k povaze distribuční databáze na ní můžeme provádět pouze omezené operace, jako je zálohování a obnova. Nemůžeme je vypustit přímo jako databáze uživatelů.
U velké databáze se spoustou replikovaných dat potřebujeme provést několik speciálních opatření ke zlepšení výkonu propustnosti replikace:
Ve výchozím nastavení je distribuční databáze vytvořena na výchozí instalační cestě nakonfigurované v SQL Server . Pokud není nakonfigurován, bude vytvořen na C : jednotce nebo ve složkách instalace serveru SQL. Pro zlepšení výkonu doporučujeme přesunout distribuční databázi na rychlejší úložiště/disk.
Počáteční velikost souboru a Automatický růst distribuční databáze bude nastavena podle nastavení počáteční velikosti souboru a automatického růstu modelové databáze. Nakonfigurujte velikost počátečního souboru na lepší hodnotu, například 10 GB v případě transačně vytížené replikace databáze. Vlastnosti Autogrowth by měly být až 512 MB nebo 1 GB pro data i soubory protokolu. Datové a protokolové soubory pak nebudou příliš fragmentovány.
Nakonfigurujte Denně nebo Rutinní úlohy zálohování zahrnout distribuční databázi pro referenční účely nebo řešení problémů v případě poškození nebo ztráty dat.
Nakonfigurujte Denní reorganizaci indexu nebo Údržba pracovních míst zahrnout distribuční databázi. Databáze zahrnuje velké vkládání dat do MSrepl_transactions a MSrepl_commands tabulky.
Poznámka:Nepřetržité dotazování na tyto 2 tabulky a DELETE z nich po úspěšném odeslání dat do databáze odběratelů zvyšuje riziko fragmentace. Přestavba těchto tabulek na plánovaném základě může zlepšit výkon distribuční databáze.
Chcete-li zobrazit a upravit kterýkoli z atributů distribuční databáze související s replikací, klikněte pravým tlačítkem na Replikace > Vlastnosti distributora :
Klikněte na elipsu tlačítko vpravo pro zobrazení podrobností o jednotlivých uvedených možnostech.
Pozor, změna jakýchkoli parametrů může ovlivnit výkon distribuční databáze. Změny proto implementujte až poté, co pečlivě vyhodnotíte všechny parametry, které chcete upravit.
Uchování transakce určuje, kolik dat by mělo být zachováno v distribuční databázi. Minimální a maximální hodnoty lze zadat v hodinách nebo dnech.
Hodnota uchování transakcí nastavená na 0 hodin označuje, že jakmile jsou záznamy úspěšně replikovány do databáze odběratelů, mohou být odstraněny z distribuční databáze. Pokud tuto hodnotu zvýšíte, zvětší se velikost distribuční databáze. Proto to musíme podle toho naplánovat.
Uchování historie určuje dobu uchování pro ukládání dat Historie výkonu transakční replikace. Ve výchozím nastavení je to 48 hodin.
Chcete-li zrušit distribuční databázi , musíme Zakázat publikování přidružené k této konkrétní distribuční databázi a poté ji zahodit pomocí jedné ze dvou metod. Jedním z nich je kombinace Zakázat publikování a Průvodce distribucí. Další používá sp_dropdistributor nebo sp_dropdistributiondb postupy. Průvodce interně používá tyto 2 postupy k zakázání distribuce a zrušení distribuční databáze.
Agenti replikace serveru SQL
Replikační agenti jsou samostatné programy odpovědné za sledování změn dat z vydavatele a šíření těchto změn do databází distributorů a předplatitelů. Jsou prováděny jako úlohy SQL Server Agent.
Nejprve se podívejme na umístění těchto samostatných programů.
Ke konfiguraci replikace potřebujeme mít komponenty replikace nainstalována pomocí instalačního programu SQL Server. Po dokončení můžeme vidět samostatné programy související s replikačním agentem dostupné v instalační cestě:
C:\Program Files\Microsoft SQL Server\130\COM
V mém případě je verze SQL Server verze 2016. V cestě je tedy méně než 130.
Pro každého replikačního agenta vidíme, že je k dispozici příslušný samostatný program:
- DISTRIB.exe – Distribuční agent
- Logread.exe – Agent čtečky protokolů
- Qrdrsvc.exe – Queue Reader Service Agent
- Replmerg.exe – Merge Replication Agent
- Snapshot.exe – Snapshot Agent
- Tablediff.exe – nástroj pro porovnání tabulek. Více podrobností můžeme získat později v tomto článku.
Nyní, když víme, za co jsou tyto samostatné programy zodpovědné a kde se nacházejí, můžeme pochopit, jak jsou spouštěny prostřednictvím SQL Server Agent Jobs.
Protože se zabýváme transakční replikací serveru SQL Server, projdeme úlohy agenta snímku, agenta čtení protokolu a agenta distribuce (stejná logika platí pro všechny ostatní agenty).
Agent snímku
Snapshot Agent se spouští ze serveru obsahujícího distribuční databázi. Připraví schéma a počáteční data všech článků obsažených v publikaci na vydavateli, vytvoří soubory snímků ve složce snímků a zaznamená podrobnosti o synchronizaci v databázi distribuce.
Z distribuce MSSnapshot_agents tabulky, můžeme identifikovat SQL Server Agent Job, který provádí aktivity Snapshot Agent. Každá publikace zahrnuje vyhrazenou úlohu SQL Server Agent, která se musí postarat o odpovědnosti agenta Snapshot.
Rozbalte SQL Server Agent a otevřete výše uvedený název úlohy. Zobrazí podrobnosti a kategorii název – REPL-Snapshot
Klikněte na Krok zobrazíte aktivity prováděné agentem Snapshot.
Kliknutím na některý jednotlivý krok zobrazíte informace o úloze agenta Snapshot.
Krok 1 zaznamená záznam do tabulky historie pokaždé, když se agent Snapshot spustí, pomocí sp_MSadd_snapshot_history postup.
Tabulka, která obsahuje historii podrobností prováděných agentem Snapshot, je MSsnapshot_history tabulky v distribuční databázi.
Bude odpovídat Zobrazit stav agenta snímku dialogové okno.
Přejděte na Krok 2 – Spustit agenta . Spustí úlohu Snapshot Agent .
V části Příkaz , nenašli jsme žádné příkazy ani dotazy T-SQL. Vypsány byly jen některé parametry. Odpověď tedy leží ve zvýrazněné části na obrázku výše. Ukazuje, že Job StepTyp je Snímek replikace který spouští samostatný program snapshot.exe k plnění povinností Snapshot Agent.
Další podrobnosti o snapshot.exe naleznete v tomto článku MSDN. Při odstraňování problémů souvisejících s replikací se také budeme zabývat podrobnostmi později.
Nakonec přejdeme ke Kroku 3 – poslední pracovní krok. Zaznamenává všechna neočekávaná vypnutí Agent Jobs a odhlašuje je.
Agent čtečky protokolů
Kdykoli je publikace nakonfigurována v databázi, všechny změny, ke kterým dojde v těchto článcích, budou označeny jako replikace v protokolu transakcí. Agent Log Reader čte tyto změny dat pomocí logread.exe a ukládá je do distribuční databáze pomocí 2 samostatných procesů:
- Čtení protokolů transakcí – používá sp_replcmds rozšířená uložená procedura pro skenování změn dat z vydavatele. Protože tato uložená procedura odkazuje na soubory DLL, interní informace o tom, jak přesně Microsoft čte soubory protokolu, nejsou identifikovány. Můžeme však vyzkoušet nedokumentované funkce jako fn_dblog() a fn_dump_dblog() abyste pochopili, jak funguje soubor protokolu transakcí.
- Zápis do distribuční databáze – používá sp_MSadd_replcmds uložená procedura v distribuční databázi zapsat binární data přečtená z transakčních protokolů databáze Publisher. Podrobnosti transakce zapíše do MSrepl_transactions tabulky a jednotlivé příkazy do MSrepl_commands stůl.
Pro každou publikovanou databázi je k dispozici pouze jedna úloha Log Reader SQL Server Agent. Jeho název můžete identifikovat následovně:
Rozbalte SQL Server Agent a otevřete výše uvedenou úlohu Log Reader Agent pro zobrazení kroků. Zobrazí kategorii úlohy pod Replication Log Reader.
Klikněte na Kroky zobrazíte jednotlivé kroky provedené agentem Log Reader Agent. Stejně jako u úlohy Snapshot Agent můžeme vidět 3 ekvivalentní kroky pro úlohu Log Reader Agent.
Krok 1 volá sp_MSadd_logreader_history postup pro protokolování zpráv historie stavu spouštění agenta Log Reader Agent do MSlogreader_history tabulka.
Krok 2 spustí proces Log Reader Agent pomocí samostatného programu logread.exe .
Další podrobnosti o logread.exe naleznete v příslušném článku MSDN. Později také prozkoumáme kritické konfigurační parametry agenta Log Reader Agent.
Krok 3 zachycuje náhlé vypnutí úlohy Log Reader Agent.
Distribuční agent
Agent distribuce (DISTRIB.exe) byl použit službou Transactional a Snapshot Replication k použití počátečních souborů snímků a přírůstkové nebo použití dostupných nevyřízených transakcí z databáze distribuce na databázi odběratelů.
Tento agent se spouští z distribučního serveru pro Push Subscriptions a Subscriber Server pro Pull Subscriptions. Abychom našli název úlohy SQL Server Agent Job, která vykonává povinnosti distribučního agenta, můžeme provést konkrétní dotaz, jak je uvedeno níže:
Rozbalte úlohu SQL Server Agent a otevřete ji, abyste viděli další informace a kategorii přiřazenou distribuci replikace.
Klikněte na Kroky – uvidíte kroky podobné dříve uvedeným krokům úloh Snapshot a Log Reader Agent.
Krok 1 volá sp_MSadd_distribution_history postup pro protokolování zpráv historie stavu spouštění agenta Log Reader Agent do MSdistribution_history tabulka.
Krok 2 spustí proces distribučního agenta (DISTRIB.exe) s výchozími parametry.
Další podrobnosti o DISTRIB.exe naleznete v článku MSDN. Dále si v dalších článcích projdeme kritické konfigurační parametry agenta distribuce.
Krok 3 zachycuje podrobnosti o náhlém vypnutí úlohy Distribučního agenta.
Profily replikačních agentů
Z Vlastností distributora , můžeme získat možnost zobrazit Profily replikačních agentů . Ponechte profily agentů na výchozí hodnoty a změňte je pouze podle potřeby pro účely odstraňování problémů.
Klikněte na Výchozí nastavení profilu pro zobrazení výchozích hodnot nakonfigurovaných pro všechny replikační agenty dostupné na serveru.
Vyberte Distribuční agenty a klikněte na elipsu vedle Výchozího profilu agenta abyste viděli nakonfigurované hodnoty. Viz obrázek níže:
Zobrazit Výchozí profil agenta z Agentů snímku Agent čtenáře:
Výchozí profil agenta pro čtečku protokolů Zástupce:
Úlohy údržby replikace
Kromě Replication Agents máme Úlohy údržby replikace .
Toto jsou úlohy SQL Server Agent vytvořené při konfiguraci transakční replikace SQL Server. Jsou k dispozici pro zajištění správného fungování transakční replikace.
Některé úlohy údržby replikace jsou nezbytné pro transakční replikaci. Pojďme je zkontrolovat.
- Čištění distribuce: Distribuce – provede sp_MSdistribution_cleanup postup k odstranění příkazů replikace z MSrepl_transactions a MSrepl_commands tabulky. Vyčištění proběhne v distribuční databázi po úspěšném odeslání příkazů do databáze odběratelů na základě hodnoty období uchování transakcí nakonfigurované v distribuční databázi. Ve výchozím nastavení se tato úloha spouští každých 10 minut v distribuční databázi. Tyto hodnoty změňte až po hloubkovém vyhodnocení.
- Agent Vyčištění historie:Distribuce – provede sp_MShistory_cleanup postup v distribuční databázi k vyčištění historických záznamů starších než období uchování historie nakonfigurované v této databázi. Ve výchozím nastavení je nakonfigurován na 48 dní a spouští se každých 10 minut. Pokud chcete tyto hodnoty změnit, pečlivě zvažte všechny aspekty.
- Platnost vypršela Vyčištění předplatného – provede sp_expired_subscription_cleanup postup v hlavní databázi pro zrušení těch předplatných, jejichž platnost vypršela nebo byla po dlouhou dobu neaktivní. Ve výchozím nastavení se tento postup provádí jednou denně.
Latence replikace a tokeny sledování
Latence replikace je čas, který proces replikace vyžaduje ke sledování jakýchkoli změn, ke kterým dochází u publikovaných článků z databáze vydavatelů, dokud nejsou úspěšně doručeny předplatiteli prostřednictvím distributora.
Latence replikace se měří v milisekundách. Cílová hodnota od 0 (replikace v reálném čase) až po velmi nízkou hodnotu (ideální případy). Je to jedno z klíčových opatření pro sledování výkonu replikace.
Latenci replikace můžeme ověřit pomocí nástroje Replication Monitor nebo vyhrazených sp_replcounters postup.
Od Monitor replikace má obnovení rychlost, může dojít k mírným odchylkám od pozorovaných hodnot. Abychom překonali drobné odchylky při výpočtu latence replikace, přijdou nás zachránit tokeny Tracer.
Klikněte na Tokeny sledování (viz obrázek výše) pro odeslání nové sady testovacích příkazů z vydavatele. Poté jej změřte, když se dostane do databáze distributorů a když byl odeslán do databáze odběratelů. Klikněte na Insert Tracer k odeslání sledovacích tokenů z databáze vydavatele:
Jakmile jsou záznamy úspěšně přijaty v Subscriber, můžeme sledovat celkovou latenci replikace pro naše aktuální nastavení. V našem případě je to 9 sekund:4 sekundy od vydavatele k distributorovi a 5 sekund od distributora k odběrateli.
Nástroj Tableiff
Nástroj Tableiff (tablediff.exe) bude nainstalováno v cestě C:\Program Files\Microsoft SQL Server\130\COM jakmile budeme mít nainstalovány komponenty replikace.
Nástroj TableDiff porovnává 2 tabulky pro nekonvergenci. To znamená, že můžeme porovnat 2 tabulky a identifikovat rozdíly mezi nimi. Poté synchronizuje cílovou tabulku ve srovnání se zdrojovou tabulkou generováním vyhrazených skriptů INSERT/UPDATE/DELETE. Další podrobnosti jsou k dispozici v oficiální dokumentaci.
Vzhledem k tomu, že SQL Server Transakční replikace se nestará o ruční změny v databázi odběratelů, může tento nástroj pomoci synchronizovat tyto druhy tabulek podle potřeby. Nemá však průvodce ani uživatelské rozhraní – můžete k němu přistupovat pouze prostřednictvím příkazového řádku nebo z dávkových souborů.
Jiné nástroje mohou srovnání a synchronizaci zjednodušit. dbForge Compare Bundle pro SQL Server kontroluje nesrovnalosti v databázích a konkrétních tabulkách je identifikuje a analyzuje. Generuje také potřebné skripty pro jejich synchronizaci. Nabízí vizuální rozhraní a spoustu možností pro rychlé a přímočaré spouštění úkolů.
Výstrahy SQL Server Agent
Všechny klíčové komponenty související s replikačními agenty jsou umístěny jako úlohy pod úlohami SQL Server Agent. Proto je důležité neustále sledovat, jak úlohy SQL Server Agent fungují, aby bylo zajištěno, že replikace bude fungovat bez problémů. Nejběžnější problémy jsou uvedeny níže:
- Problém s oprávněními při provádění kterékoli z úloh replikačního agenta
- Problém s oprávněními při provádění kterékoli z úloh údržby replikace.
- Problém s oprávněními pro přístup k databázi vydavatele, distribuce nebo odběratelů.
- SQL Server Agent není nakonfigurován tak, aby se spouštěl automaticky při restartu serveru.
- Několik dalších problémů s daty souvisejících s replikací, jako jsou konflikty, chybějící data a tak dále.
To je důvod, proč bychom měli mít zavedený řádný výstražný mechanismus, abychom o jakémkoli problému okamžitě informovali DBA nebo jinou osobu.
Abychom upozornili správce databází nebo jiné osoby v případě jakýchkoli selhání nebo chyb úlohy, měli bychom nakonfigurovat poštu databáze tak, aby zasílala e-mailová upozornění. Umožňuje DBA reagovat okamžitě a vyřešit problém. O tom, jak nakonfigurovat Database Mail and Alerts, pojednáme později v samostatném článku.
Při konfiguraci replikace SQL Server ve výchozím nastavení vytváří níže uvedenou sadu výstrah. Můžete je snadno nakonfigurovat podle požadovaných kritérií. Zajišťuje také zasílání oznámení požadovaným osobám k okamžité akci.
Závěr
Děkujeme, že jste si prošli další velký článek o replikaci. Doufám, že to pomohlo objasnit vnitřní části transakční replikace a podrobnosti o distribuční databázi, replikačních agentech a samostatných programech, které jsou za ně odpovědné. Identifikovali jsme také latenci replikace, výstrahy a tokeny sledování.
Nyní se můžeme ponořit hlouběji a naučit se, jak zacházet a řešit problémy s replikací profesionálně. Zůstaňte naladěni na další článek!