SQL-servertransaktionell replikering är en av de vanligaste replikeringsteknikerna som används för att kopiera eller distribuera data över flera destinationer. I den tidigare artikeln diskuterade vi SQL Server-replikering, typer av replikering och de grundläggande internerna om hur transaktionsreplikeringen fungerar. Nu ska vi dyka in i Advanced Internals om hur SQL Server Transactional Replication fungerar.
Transaktionell replikeringsarkitektur
Innan vi börjar rekommenderar jag att du uppdaterar dina kunskaper med min tidigare artikel här.
Låt oss börja med att titta på SQL Server Transactional Replication Architecture som visas nedan från Microsofts dokumentation.
I Publisher Database , skapa en Publikation som omfattar listan över artiklar (Tabell , Visningar , etc.) som du behöver replikera till prenumeranten databas. När artiklarna har aktiverats för replikering kommer alla ändringar som sker på dessa artiklar att markeras för replikering i databasen Transactional Logs of Publisher.
SQL Server Transactional Repplication kan initieras från Publisher till Distributör och sedan till Prenumeranten databas via Snapshot Agent eller Full Säkerhetskopiering . Snapshot-agenten kan utföra initieringen via Replication Configuration Wizard . Den fullständiga säkerhetskopieringen stöds endast via T-SQL-satser.
Log Reader Agent skannar Transaktionsloggen för Publisher-databasen för att upptäcka spårade ändringar som är markerade för replikering. Den ignorerar andra ändringar som registrerats i transaktionsloggarna och kopierar dataändringar från transaktionsloggen till distributionsdatabasen.
Distributionsdatabasen kan vara antingen i Publisher eller Subscriber, eller så kan den vara i en annan oberoende SQL Server-instans. Observera följande saker:
- Log Reader Agent körs kontinuerligt från distributörsservern för att söka efter nya kommandon markerade för replikering. Men om du inte vill köra kontinuerligt och istället vill köra enligt ett schema, kan vi ändra Log Reader Agent SQL-jobbet som kommer att skapas.
- Log Reader Agent hämtar alla poster som är markerade för replikering från transaktionsloggningsbatcherna och skickar dem till distributionsdatabasen.
- Log Reader Agent hämtar endast ingångna transaktioner från Transactional Log of Publisher Database. Så alla långvariga frågor i Publisher-databasen kan direkt påverka replikering eftersom den väntar på att den aktiva transaktionen ska slutföras.
Distributionsagenten hämtar alla odistribuerade nya kommandon från distributionsdatabasen och tillämpar dem på prenumerationsdatabasen via antingen Push eller dra Mekanism .
- Push-prenumeration – Distributören tar ägarskap för att tillämpa ändringar från distributionsdatabasen på abonnenten.
- Pull-prenumeration – Prenumeranten databasen tar äganderätten för att hämta ändringar från distributionsdatabasen till abonnenten.
När posterna väl har distribuerats från distribution till prenumerantdatabasen kommer de att markeras som Distribuerade och även markerad för radering från distributionsdatabasen .
Ett av de viktigaste replikeringsunderhållsjobben är Distributionsrensningen :Distributionsjobbet körs var tionde minut för att ta bort distribuerade poster från distributionsdatabasen för att behålla storleken på distributionsdatabasen under kontroll.
Därför är vårt mål för den aktuella artikeln att utforska följande ämnen:
- Distributionsdatabas
- Replikeringsagenter
- Snapshot Agent
- Log Reader Agent
- Distributionsagent
- Replikeringsagentprofiler
- Replikeringsunderhållsjobb
- Replikeringslatens och spårningstokens
- TableDiff Utility
- SQL Server Agent Alerts
SQL Server Distribution Database
En distributionsdatabas är en systemdatabas som skapas under konfigurering av replikering. Det är hjärtat i replikering eftersom det mesta av processen tar slut i en distributionsdatabas.
På grund av distributionsdatabasens natur kan vi endast utföra begränsade operationer på den, såsom säkerhetskopiering och återställning. Vi kan inte släppa det direkt som användardatabaser.
För en enorm databas med massor av data som replikeras behöver vi vidta några speciella åtgärder för att förbättra replikeringsgenomströmningsprestanda:
Som standard skapas distributionsdatabasen på standardinstallationssökvägen konfigurerad i SQL Server . Om den inte är konfigurerad kommer den att skapas på C : enhet eller i installationsmapparna för SQL Server. Vi rekommenderar att du flyttar distributionsdatabasen till en snabbare lagring/disk för att förbättra prestandan.
Initial filstorlek och Autotillväxt av distributionsdatabasen kommer att ställas in enligt modelldatabasens initiala filstorlek och autotillväxtinställningar. Konfigurera den ursprungliga filstorleken till ett bättre värde som 10 GB vid transaktionsupptagen databasreplikering. Autogrowth-egenskaperna bör vara upp till 512 MB eller 1 GB för både data- och loggfiler. Då blir det inte mycket fragmentering av data och loggfiler.
Konfigurera Dagligen eller Rutinmässiga säkerhetskopieringsjobb att inkludera distributionsdatabasen för referensändamål eller felsökning i händelse av eventuell datakorruption eller förlust.
Konfigurera Daily Index Reorganization eller Underhåll jobb att inkludera distributionsdatabasen. Databasen involverar enorma datainsättningar i MSrepl_transactions och MSrepl_commands tabeller.
Obs:Kontinuerlig avfrågning av dessa två tabeller och DELETE från dem efter att data har skickats till prenumerantdatabasen ökar risken för fragmentering. Att bygga om dessa tabeller på schemalagd basis kan förbättra distributionsdatabasens prestanda.
För att visa och ändra någon av distributionsdatabasens attribut relaterade till replikering, högerklicka på replikering > Distributörsegenskaper :
Klicka på ellipsen knappen till höger för att se mer information om de individuella alternativen som listas.
Var uppmärksam, att ändra alla parametrar kan påverka distributionsdatabasens prestanda. Implementera därför ändringar först efter att du noggrant utvärderat alla parametrar du vill ändra.
Transaktionsbevarande anger hur mycket data som ska lagras i distributionsdatabasen. Minsta och högsta värden kan anges i timmar eller dagar.
Transaktionsretentionsvärdet satt till 0 timmar indikerar att när poster väl har replikerats till prenumerantdatabasen kan de raderas från distributionsdatabasen. Om du ökar detta värde kommer storleken på distributionsdatabasen att öka. Därför måste vi planera det därefter.
Historikbevarande anger lagringsperioden för att lagra data för transaktionsreplikeringsprestandahistorik. Som standard är det 48 timmar.
Att släppa en distributionsdatabas måste vi inaktivera publicering associerad med den specifika distributionsdatabasen och släpp den sedan med någon av de två metoderna. Den ena är en kombination av Inaktivera publicering och distributionsguiden. En annan använder sp_dropdistributor eller sp_dropdistributiondb förfaranden. Guiden använder internt dessa två procedurer för att inaktivera distribution och släppa distributionsdatabasen.
SQL-serverreplikeringsagenter
Replikeringsagenter är fristående program som ansvarar för att spåra dataändringar från Publisher och sprida dessa ändringar till Distributörs- och Prenumerantdatabaser. De körs som SQL Server Agent-jobb.
Låt oss först se var dessa fristående program finns.
För att konfigurera replikering måste vi ha replikeringskomponenterna installeras via installationsprogrammet för SQL Server. När det är klart kan vi se de replikeringsagentrelaterade fristående programmen tillgängliga i installationssökvägen:
C:\Program Files\Microsoft SQL Server\130\COM
I mitt fall är versionen av SQL Server-versionen 2016. Därför är den under 130 i sökvägen.
För varje replikeringsagent kan vi se respektive fristående program tillgängligt:
- DISTRIB.exe – Distributionsagent
- Logread.exe – Log Reader Agent
- Qrdrsvc.exe – Queue Reader Service Agent
- Replmerg.exe – Sammanfoga replikeringsagent
- Snapshot.exe – Snapshot Agent
- Tablediff.exe – Verktyg för att jämföra tabeller. Vi kan komma in på mer detaljer längre fram i den här artikeln.
Nu när vi vet vad dessa fristående program är ansvariga för och var de finns, kan vi förstå hur de exekveras via SQL Server Agent Jobs.
Eftersom vi har att göra med SQL Server Transactional Replication kommer vi att gå igenom jobben Snapshot Agent, Log Reader Agent och Distribution Agent (samma logik gäller för alla andra agenter).
Snapshot Agent
Snapshot-agenten körs från servern som innehåller distributionsdatabasen. Den förbereder schemat och initiala data för alla artiklar som ingår i en publikation på en utgivare, skapar ögonblicksbildfilerna i ögonblicksbildsmappen och registrerar synkroniseringsdetaljerna i distributionsdatabasen.
Från distributionen MSSnapshot_agents tabell kan vi identifiera SQL Server Agent Job som gör Snapshot Agent-aktiviteterna. Varje publikation innefattar ett dedikerat SQL Server Agent-jobb som måste ta hand om Snapshot Agent-ansvaret.
Expandera SQL Server Agent och öppna jobbnamnet som nämns ovan. Den visar detaljerna och Kategorien namn – REPL-Snapshot
Klicka på steget för att se aktiviteter som utförs av Snapshot-agenten.
Klicka på ett individuellt steg för att se informationen om Snapshot-agentjobbet.
Steg 1 loggar en post i historiktabellen varje gång Snapshot-agenten startar med hjälp av sp_MSadd_snapshot_history förfarande.
Tabellen som innehåller historiken för detaljerna som körs av Snapshot-agenten är MSsnapshot_history tabell i distributionsdatabasen.
Det kommer att matcha Visa status för ögonblicksbildagent dialogfönster.
Gå till Steg 2 – Kör agent . Det kommer att starta Snapshot Agent-jobbet .
Under kommandot , vi kunde inte hitta några T-SQL-satser eller frågor. Det fanns bara några parametrar listade. Så svaret ligger i det markerade avsnittet på illustrationen ovan. Det visar att Job StepTyp är Snapshot av replikering som startar snapshot.exe fristående program för att utföra Snapshot Agent-ansvaret.
Mer information om snapshot.exe finns i den här MSDN-artikeln. Vi kommer också att gå in i detalj när vi felsöker replikeringsrelaterade problem senare.
Slutligen går vi till Steg 3 – det sista jobbsteget. Den fångar alla oväntade avstängningar av Agent Jobs och loggar ut dem.
Log Reader Agent
Närhelst publikationen konfigureras på en databas, markeras alla ändringar som händer med dessa artiklar för replikering i transaktionsloggen. Log Reader Agent läser dessa dataändringar via logread.exe och lagrar dem i distributionsdatabasen via två separata processer:
- Läs transaktionsloggar – den använder sp_replcmds utökad lagrad procedur för att söka efter dataändringar från utgivaren. Eftersom denna lagrade procedur refererar till DLL-filer, identifieras inte interna filer om exakt hur Microsoft läser loggfiler. Däremot kan vi prova odokumenterade funktioner som fn_dblog() och fn_dump_dblog() för att förstå hur transaktionsloggfilen fungerar.
- Skriv till distributionsdatabasen – den använder sp_MSadd_replcmds lagrad procedur i distributionsdatabasen för att skriva binära data som läses från utgivardatabasens transaktionsloggar. Den skriver transaktionsinformationen till MSrepl_transactions tabell och individuella kommandon till MSrepl_commands tabell.
Endast ett Log Reader SQL Server Agent-jobb är tillgängligt för varje publicerad databas. Du kan identifiera dess namn enligt nedan:
Expandera SQL Server Agent och öppna ovanstående Log Reader Agent-jobb för att se stegen. Det kommer att visa jobbet Сategory under Replikeringsloggläsare.
Klicka på Steg för att se enskilda steg utförda av Log Reader Agent. Precis som med Snapshot Agent-jobbet kan vi se tre motsvarande steg för Log Reader Agent-jobbet.
Steg 1 anropar sp_MSadd_logreader_history procedur för att logga uppstartsstatushistorikmeddelanden från Log Reader Agent till MSlogreader_history bord.
Steg 2 startar Log Reader Agent-processen med det fristående programmet logread.exe .
Du kan hitta mer information om logread.exe i respektive MSDN-artikel. Senare kommer vi också att undersöka de kritiska konfigurationsparametrarna för Log Reader Agent.
Steg 3 fångar en abrupt avstängning av Log Reader Agent-jobbet.
Distributionsagent
Distribution Agent (DISTRIB.exe) användes av Transactional and Snapshot Replication för att applicera de initiala ögonblicksbilderna och inkrementella eller applicera tillgängliga väntande transaktioner från distributionsdatabasen på abonnentdatabasen.
Denna agent körs från distributörsservern för Push-prenumerationerna och abonnentservern för Pull-prenumerationerna. För att hitta namnet på SQL Server Agent Job som utför distributionsagentens ansvar kan vi köra den specifika frågan enligt nedan:
Expandera SQL Server Agent-jobbet och öppna det för att se mer information och kategorin som tilldelats replikeringsdistributionen.
Klicka på Steg – du kommer att se stegen som liknar de tidigare exponerade stegen för jobben Snapshot och Log Reader Agent.
Steg 1 anropar sp_MSadd_distribution_history procedur för att logga uppstartsstatushistorikmeddelanden från Log Reader Agent till MSdistribution_history bord.
Steg 2 startar distributionsagentprocessen (DISTRIB.exe) med standardparametrarna.
Mer information om DISTRIB.exe finns i MSDN-artikeln. Vidare kommer vi att gå igenom de kritiska konfigurationsparametrarna för distributionsagenten i nästa artiklar.
Steg 3 fångar information om den abrupta avstängningen av distributionsagentjobbet.
Replikeringsagentprofiler
Från Distributörsegenskaper , kan vi få möjlighet att visa replikeringsagentprofilerna . Lämna agentprofilerna till standardvärdena och ändra endast efter behov för felsökningsändamål.
Klicka på Profilstandard för att se standardvärdena som är konfigurerade för alla replikeringsagenter som är tillgängliga på servern.
Välj Distributionsagenter och klicka på ellipsen knappen bredvid Standardagentprofil för att se de konfigurerade värdena. Se illustrationen nedan:
Visa standardagentprofilen av Snapshot Agents läsaragent:
Standardagentprofil för loggläsaren Agent:
Replikeringsunderhållsjobb
Förutom replikeringsagenter har vi replikeringsunderhållsjobb .
Dessa är SQL Server Agent-jobb som skapats under konfigurering av SQL Server Transactional Replication. De är tillgängliga för att säkerställa att transaktionsreplikeringen fungerar korrekt.
Vissa jobb på replikeringsunderhåll är viktiga för transaktionsreplikering. Låt oss granska dem.
- Rengöring av distribution: Distribution – kör sp_MSdistribution_cleanup procedur för att ta bort replikeringskommandon från MSrepl_transactions och MSrepl_commands tabeller. Rensning sker i distributionsdatabasen efter att kommandon har skickats till abonnentdatabasen baserat på värdet för transaktionslagringsperioden som konfigurerats i distributionsdatabasen. Som standard körs det här jobbet var tionde minut i distributionsdatabasen. Ändra dessa värden endast efter en djupgående utvärdering.
- Agent Historisrensning:distribution – kör sp_MShistory_cleanup procedur i distributionsdatabasen för att rensa upp historiska poster som är äldre än historiklagringsperioden som konfigurerats i den databasen. Som standard är det konfigurerat för 48 dagar och körs var tionde minut. Om du vill ändra dessa värden, överväg alla aspekter noggrant.
- Upphört Upprensning av prenumerationer – kör sp_expired_subscription_cleanup procedur i huvuddatabasen för att ta bort de prenumerationer som löpt ut eller varit inaktiva under en lång tid. Som standard körs denna procedur en gång om dagen.
Replikeringslatens och spårningstokens
replikeringsfördröjning är den tid som krävs av replikeringsprocessen för att spåra eventuella ändringar som sker på publicerade artiklar från utgivarens databas tills den levereras framgångsrikt till abonnenten via distributören.
Replikationslatens mäts i millisekunder. Målvärdet 0 (realtidsreplikering) till ett mycket lågt värde (idealfall). Det är en av nyckelåtgärderna för att övervaka replikeringsprestanda.
Vi kan verifiera replikeringsfördröjningen med hjälp av Replication Monitor eller de dedikerade sp_replcounters förfarande.
Sedan replikeringsövervakaren har uppdateringen kan det finnas små avvikelser från de observerade värdena. För att övervinna de små avvikelserna när vi beräknar replikeringsfördröjningen kommer Tracer Tokens till vår räddning.
Klicka på Tracer Tokens fliken (se bilden ovan) för att skicka en ny uppsättning testkommandon från utgivaren. Mät sedan den när den når distributörsdatabasen och när den skickades till abonnentdatabasen. Klicka på Infoga spårare för att skicka spårningstoken från Publisher-databasen:
När posterna väl har tagits emot i Subscriber kan vi spåra den totala replikeringsfördröjningen för vår nuvarande installation. I vårt fall är det 9 sekunder:4 sekunder från utgivare till distributör och 5 sekunder från distributör till prenumerant.
Tablediff Utility
Tablediff-verktyg(tablediff.exe) kommer att installeras i sökvägen C:\Program Files\Microsoft SQL Server\130\COM när vi har installerat replikeringskomponenterna.
TableDiff-verktyget jämför 2 tabeller för icke-konvergens. Det betyder att vi kan jämföra två tabeller och identifiera skillnaderna mellan dem. Sedan synkroniserar den destinationstabellen jämfört med källtabellen genom att generera dedikerade INSERT/UPDATE/DELETE-skript. Mer information finns i den officiella dokumentationen.
Eftersom SQL Server Transactional Replication inte bryr sig om manuella ändringar i abonnentdatabasen, kan detta verktyg hjälpa till att synkronisera den här typen av tabeller när och när det behövs. Den har dock ingen guide eller gränssnitt – du kan bara komma åt den via kommandotolken eller från batchfiler.
Andra verktyg kan göra jämförelse och synkronisering enklare. dbForge Compare Bundle för SQL Server kontrollerar avvikelserna i databaserna och specifika tabeller identifierar och analyserar dem. Den genererar också de nödvändiga skripten för att synkronisera dem. Den erbjuder ett visuellt gränssnitt och en massa alternativ för att köra uppgifterna snabbt och enkelt.
SQL Server Agent Alerts
Alla nyckelkomponenter relaterade till replikeringsagenter finns som jobb finns under SQL Server Agent-jobben. Därför är det viktigt att övervaka hur SQL Server Agent-jobb fungerar kontinuerligt för att säkerställa att replikering fungerar utan problem. De vanligaste problemen är nedan:
- Behörighetsproblem för att utföra något av replikeringsagentjobben
- Behörighetsproblem för att utföra något av replikeringsunderhållsjobben.
- Behörighetsproblem för åtkomst till utgivare eller distribution eller prenumerantdatabas.
- SQL Server Agent är inte konfigurerad att starta automatiskt vid omstart av servern.
- Flera andra replikeringsrelaterade dataproblem som konflikter, saknade data och så vidare.
Det är därför vi bör ha en ordentlig varningsmekanism på plats för att omedelbart meddela DBA eller annan person om något problem.
För att varna DBA:er eller andra personer vid eventuella jobbfel eller fel, bör vi konfigurera Databas Mail för att skicka e-postvarningar. Det låter DBA svara på en gång och åtgärda problemet. Vi kommer att diskutera hur du konfigurerar databaspost och varningar i en separat artikel senare.
När du konfigurerar replikering skapar SQL Server som standard följande uppsättning varningar. Du kan enkelt konfigurera dem för de kriterier som krävs. Det säkerställer också att meddelanden skickas till nödvändiga personer för omedelbar åtgärd.
Slutsats
Tack för att du gick igenom ännu en stor artikel om replikering. Jag hoppas att det hjälpte till att förtydliga de interna funktionerna i transaktionsreplikering och detaljerna om distributionsdatabas, replikeringsagenter och fristående program som ansvarar för dessa. Vi identifierade också replikeringsfördröjningen, varningar och spårningstokens.
Nu kan vi dyka djupare och lära oss att behandla och lösa replikeringsproblem professionellt. Håll utkik efter nästa artikel!