SQL Server Transactional Replication Internals – Del 2

SQL-servertransaktionel replikering er en af ​​de mest almindeligt anvendte replikeringsteknikker, der bruges til at kopiere eller distribuere data på tværs af flere destinationer. I den forrige artikel diskuterede vi SQL Server-replikering, typer af replikering og de grundlæggende interne funktioner om, hvordan transaktionsreplikeringen fungerer. Nu skal vi dykke ned i Advanced Internals af, hvordan SQL Server Transactional Replication fungerer.

Transaktionel replikeringsarkitektur

Før vi starter, anbefaler jeg dig at genopfriske din viden med min tidligere artikel her.

Lad os starte med at se på SQL Server Transactional Replication Architecture vist nedenfor fra Microsoft-dokumentation.

I Publisher Database , opret en Publikation omfattende listen over artikler (Tabeller , Visninger osv.), som du skal replikere til Abonnenten database. Når artiklerne er aktiveret til replikering, vil alle ændringer, der sker på disse artikler, blive markeret til replikering i Transactional Logs of Publisher-databasen.

SQL Server Transactional Replikering kan initialiseres fra Publisher til Distributør og derefter til Abonnenten database via Snapshot Agent eller Fuld Sikkerhedskopier . Snapshot-agenten kan udføre initialiseringen via Replikeringskonfigurationsguiden . Den fulde backup understøttes kun via T-SQL-sætninger.

Loglæseragenten scanner Transaktionsloggen for Publisher-databasen for at registrere de sporede ændringer, der er markeret til replikering. Den ignorerer andre ændringer, der er registreret i transaktionsloggene og kopierer dataændringer fra transaktionsloggen til distributionsdatabasen.

Distributionsdatabasen kan være enten i Publisher eller Subscriber, eller den kan være i en anden uafhængig SQL Server-instans. Bemærk følgende ting:

• Log Reader Agent kører kontinuerligt fra distributørserveren for at scanne efter nye kommandoer, der er markeret til replikering. Men hvis du ikke ønsker at køre kontinuerligt og ønsker at køre efter en tidsplan i stedet, kan vi ændre Log Reader Agent SQL Job, der vil blive oprettet.
• Log Reader Agent henter alle poster, der er markeret til replikering, fra transaktionslog i batches og sender dem til distributionsdatabasen.
• Log Reader Agent henter kun forpligtede transaktioner fra Transactional Log of Publisher Database. Så alle langvarige forespørgsler på Publisher-databasen kan direkte påvirke replikering, da den venter på, at den aktive transaktion er fuldført.

Distributionsagenten henter alle ikke-distribuerede nye kommandoer fra distributionsdatabasen og anvender dem til abonnementsdatabasen via enten Push eller Træk Mekanisme .

• Push-abonnement – Distributøren tager ejerskab til at anvende ændringer fra distributionsdatabasen til abonnenten.
• Træk abonnement – ​​ Abonnenten databasen tager ejerskab til at hente ændringer fra distributionsdatabasen til abonnenten.

Når posterne er distribueret korrekt fra distribution til abonnentdatabasen, vil de blive markeret som Distribueret og også markeret til sletning fra distributionsdatabasen .

Et af de vigtigste replikeringsvedligeholdelsesjob er Distributionsoprydning :Distributionsjobbet kører hvert 10. minut for at slette distribuerede poster fra distributionsdatabasen for at bevare størrelsen på distributionsdatabasen under kontrol.

Derfor er vores mål for den aktuelle artikel at udforske følgende emner:

• Distributionsdatabase
• Replikeringsagenter
  • Snapshot-agent
  • Loglæseragent
  • Distributionsagent
• Replikeringsagentprofiler
• Replikeringsvedligeholdelsesjob
• Replikeringsforsinkelse og sporingstokens
• TableDiff Utility
• SQL Server Agent Alerts

SQL-serverdistributionsdatabase

En distributionsdatabase er en systemdatabase oprettet under konfiguration af replikering. Det er hjertet i replikering, da det meste af processen løber tør for en distributionsdatabase.

På grund af distributionsdatabasens natur kan vi kun udføre begrænsede handlinger på den, såsom sikkerhedskopiering og gendannelse. Vi kan ikke droppe det direkte ligesom brugerdatabaser.

For en enorm database med masser af data, der replikeres, er vi nødt til at tage nogle få særlige foranstaltninger for at forbedre replikeringsgennemstrømningsydelsen:

Som standard oprettes distributionsdatabasen på standardinstallationsstien konfigureret i SQL Server . Hvis den ikke er konfigureret, oprettes den på C : drev eller i SQL Server-installationsmapperne. Vi vil anbefale, at du flytter distributionsdatabasen til en hurtigere lagring/disk for at forbedre ydeevnen.

Oprindelig filstørrelse og Autovækst af distributionsdatabasen vil blive indstillet i henhold til modeldatabasens oprindelige filstørrelse og autovækstindstillinger. Konfigurer den oprindelige filstørrelse til en bedre værdi som f.eks. 10 GB i tilfælde af den transaktionelt travle databasereplikering. Autogrowth-egenskaberne skal være op til 512 MB eller 1 GB for både data- og logfiler. Så vil der ikke være meget fragmentering af data og logfiler.

Konfigurer Daglig eller Rutinemæssig backup-job at inkludere distributionsdatabasen til referenceformål eller fejlfinding i tilfælde af datakorruption eller -tab.

Konfigurer Daglig indeksomlægning eller Vedligeholdelse job at inkludere distributionsdatabasen. Databasen involverer enorme dataindsættelser i MSrepl_transactions og MSrepl_commands tabeller.

Bemærk:Kontinuerlig polling på disse 2 tabeller og SLET fra dem efter at have sendt data til abonnentdatabasen øger risikoen for fragmentering. Genopbygning af disse tabeller på en planlagt basis kan forbedre distributionsdatabasens ydeevne.

For at se og ændre nogen af ​​distributionsdatabaseattributterne relateret til replikering skal du højreklikke på replikering > Distributøregenskaber :

Klik på ellipsen knappen til højre for at se flere detaljer om de individuelle muligheder, der er angivet.

Vær opmærksom, ændring af parametre kan påvirke distributionsdatabasens ydeevne. Implementer derfor kun ændringer, efter at du omhyggeligt har evalueret alle parametre, du ønsker at ændre.

Transaktionsopbevaring angiver, hvor meget data der skal opbevares i distributionsdatabasen. Minimum- og maksimumværdierne kan angives i timer eller dage.

Transaktionsopbevaringsværdien indstillet til 0 timer angiver, at når poster er blevet replikeret til abonnentdatabasen, kan de slettes fra distributionsdatabasen. Hvis du øger denne værdi, vil distributionsdatabasens størrelse øges. Derfor er vi nødt til at planlægge det i overensstemmelse hermed.

Historieopbevaring specificerer opbevaringsperioden for at gemme data for transaktionsreplikeringsydelseshistorik. Som standard er det 48 timer.

At slippe en distributionsdatabase , skal vi deaktivere udgivelse knyttet til den pågældende distributionsdatabase, og slip den derefter ved hjælp af en af ​​de to metoder. Den ene er en kombination af Deaktiver udgivelse og distributionsguiden. En anden bruger sp_dropdistributor eller sp_dropdistributiondb procedurer. Guiden bruger internt disse 2 procedurer til at deaktivere distribution og slette distributionsdatabasen.

SQL-serverreplikeringsagenter

Replikeringsagenter er selvstændige programmer, der er ansvarlige for at spore dataændringer fra Publisher og udbrede disse ændringer til distributør- og abonnentdatabaser. De udføres som SQL Server Agent-job.

Lad os først se placeringen af ​​disse selvstændige programmer.

For at konfigurere replikering skal vi have replikeringskomponenterne installeret via SQL Server-installationsprogrammet. Når du er færdig, kan vi se de replikeringsagent-relaterede selvstændige programmer tilgængelige i installationsstien:

C:\Program Files\Microsoft SQL Server\130\COM

I mit tilfælde er versionen af ​​SQL Server-versionen 2016. Derfor er den under 130 i stien.

For hver replikeringsagent kan vi se det respektive selvstændige program tilgængeligt:

• DISTRIB.exe – Distributionsagent
• Logread.exe – Log Reader Agent
• Qrdrsvc.exe – Kølæserserviceagent
• Replmerg.exe – Flet replikeringsagent
• Snapshot.exe – Snapshot Agent
• Tablediff.exe – Værktøj til at sammenligne tabeller. Vi kan komme ind på flere detaljer senere i denne artikel.

Nu hvor vi ved, hvad disse selvstændige programmer er ansvarlige for, og hvor de er placeret, kan vi forstå, hvordan de udføres via SQL Server Agent Jobs.

Da vi har at gøre med SQL Server Transactional Replication, vil vi gennemgå Snapshot Agent, Log Reader Agent og Distribution Agent jobs (den samme logik gælder for alle andre agenter).

Snapshot Agent

Snapshot-agenten kører fra serveren med distributionsdatabasen. Den forbereder skemaet og indledende data for alle artikler, der er inkluderet i en publikation på en udgiver, opretter snapshot-filerne i snapshot-mappen og registrerer synkroniseringsdetaljerne i distributionsdatabasen.

Fra distributionen MSSnapshot_agents tabel, kan vi identificere SQL Server Agent Job, der udfører Snapshot Agent aktiviteterne. Hver udgivelse involverer et dedikeret SQL Server Agent-job, der skal tage sig af Snapshot Agent-ansvaret.

Udvid SQL Server Agent og åbn jobnavnet nævnt ovenfor. Det vil vise detaljerne og Kategorien navn – REPL-snapshot

Klik på trinnet for at se aktiviteter udført af Snapshot-agenten.

Klik på et enkelt trin for at se oplysningerne om Snapshot-agentjobbet.

Trin 1 logger en post til historiktabellen, hver gang Snapshot-agenten starter ved at bruge sp_MSadd_snapshot_history procedure.

Tabellen, der indeholder historikken for detaljerne udført af Snapshot-agenten, er MSsnapshot_history tabel i distributionsdatabasen.

Det vil matche Se Snapshot Agent Status dialogvindue.

Gå til Trin 2 – Kør agent . Det vil starte Snapshot Agent-jobbet .

Under kommandoen , kunne vi ikke finde nogen T-SQL-udsagn eller forespørgsler. Der var kun nogle parametre angivet. Så svaret ligger i det fremhævede afsnit på ovenstående illustration. Det viser, at jobtrinnetType er Snapshot af replikering som starter snapshot.exe selvstændigt program for at udføre Snapshot Agent-ansvaret.

For flere detaljer om snapshot.exe, se denne MSDN-artikel. Vi vil også gå i detaljer, mens vi fejlfinder de replikeringsrelaterede problemer senere.

Til sidst går vi til trin 3 – det sidste jobtrin. Den fanger eventuelle uventede nedlukninger af Agent Jobs og logger dem ud.

Loglæseragent

Når udgivelsen er konfigureret på en database, bliver alle ændringer, der sker med disse artikler, markeret til replikering i transaktionsloggen. Log Reader Agent læser disse dataændringer via logread.exe og gemmer dem i distributionsdatabasen via 2 separate processer:

• Læs transaktionslogfiler – den bruger sp_replcmds udvidet lagret procedure til at scanne for dataændringer fra udgiveren. Da denne lagrede procedure refererer til DLL-filer, identificeres interne oplysninger om, hvordan Microsoft nøjagtigt læser logfiler. Vi kan dog prøve udokumenterede funktioner som fn_dblog() og fn_dump_dblog() for at forstå, hvordan transaktionslogfilen fungerer.

• Skriv til distributionsdatabasen – den bruger sp_MSadd_replcmds gemt procedure i distributionsdatabasen for at skrive de binære data, der er læst fra udgiverdatabasens Transactional Logs. Den skriver transaktionsdetaljerne til MSrepl_transactions tabel og individuelle kommandoer til MSrepl_commands tabel.

Kun ét Log Reader SQL Server Agent-job er tilgængeligt for hver publiceret database. Du kan identificere dens navn som vist nedenfor:

Udvid SQL Server Agent og åbn ovenstående Log Reader Agent job for at se trinene. Det vil vise jobbet Сategory under Replikeringsloglæser.

Klik på Trin for at se individuelle trin udført af Log Reader Agent. Som med Snapshot Agent-jobbet kan vi se 3 tilsvarende trin for Log Reader Agent-jobbet.

Trin 1 kalder sp_MSadd_logreader_history procedure for at logge opstartsstatushistorikken for Log Reader Agent til MSlogreader_history tabel.

Trin 2 starter Log Reader Agent-processen ved hjælp af logread.exe selvstændigt program .

Du kan finde flere detaljer om logread.exe i den respektive MSDN-artikel. Senere vil vi også undersøge de kritiske konfigurationsparametre for Log Reader Agent.

Trin 3 fanger en brat nedlukning af Log Reader Agent-jobbet.

Distributionsagent

Distribution Agent (DISTRIB.exe) blev brugt af Transactional and Snapshot Replication til at anvende de indledende snapshot-filer og inkrementelle eller anvende tilgængelige afventende transaktioner fra distributionsdatabasen til abonnentdatabasen.

Denne agent kører fra distributørserveren for Push-abonnementerne og abonnentserveren for Pull-abonnementerne. For at finde navnet på det SQL Server-agentjob, der udfører distributionsagentansvaret, kan vi udføre den specifikke forespørgsel som vist nedenfor:

Udvid SQL Server Agent-jobbet, og åbn det for at se flere oplysninger og den kategori, der er tildelt replikeringsdistributionen.

Klik på Trin – du vil se trin, der ligner de tidligere eksponerede trin i Snapshot- og Log Reader Agent-jobbene.

Trin 1 kalder sp_MSadd_distribution_history procedure for at logge opstartsstatushistorikkens meddelelser fra Log Reader Agent til MSdistribution_history tabel.

Trin 2 starter distributionsagentprocessen (DISTRIB.exe) med standardparametrene.

For flere detaljer om DISTRIB.exe, se MSDN-artiklen. Yderligere vil vi gennemgå de kritiske konfigurationsparametre for distributionsagenten i de næste artikler.

Trin 3 fanger detaljer om den pludselige nedlukning af distributionsagentjobbet.

Replikeringsagentprofiler

Fra Distributøregenskaber , kan vi få mulighed for at se replikeringsagentprofilerne . Overlad agentprofilerne til standardværdierne, og skift kun efter behov til fejlfindingsformål.

Klik på Profilstandarder for at se standardværdierne, der er konfigureret for alle replikeringsagenter, der er tilgængelige på serveren.

Vælg Distributionsagenter og klik på ellipsen knappen ud for Standard agentprofil for at se de konfigurerede værdier. Se illustrationen nedenfor:

Se Standardagentprofilen af Snapshot-agenterne læseagent:

Standard agentprofil til Loglæseren Agent:

Replikeringsvedligeholdelsesjob

Udover replikeringsagenter har vi replikeringsvedligeholdelsesjob .

Disse er SQL Server Agent-job, der er oprettet under konfiguration af SQL Server Transactional Replication. De er tilgængelige for at sikre, at transaktionsreplikeringen fungerer korrekt.

Nogle opgaver med replikeringsvedligeholdelse er afgørende for transaktionsreplikering. Lad os gennemgå dem.

• Distributionsoprydning: Distribution – udfører sp_MSdistribution_cleanup procedure for at slette replikeringskommandoer fra MSrepl_transactions og MSrepl_commands tabeller. Oprydning sker i distributionsdatabasen, efter at kommandoer er blevet sendt til abonnentdatabasen baseret på værdien for transaktionsretentionsperioden, der er konfigureret i distributionsdatabasen. Som standard kører dette job hvert 10. minut på distributionsdatabasen. Ændre kun disse værdier efter en dybtgående evaluering.

• Agent Oprydning i historie:distribution – udfører sp_MShistory_cleanup procedure i distributionsdatabasen for at rydde op i historiske poster, der er ældre end den historikopbevaringsperiode, der er konfigureret i den pågældende database. Som standard er den konfigureret i 48 dage og udføres hvert 10. minut. Hvis du vil ændre disse værdier, skal du overveje alle aspekter nøje.

• Udløbet Oprydning af abonnement – udfører sp_expired_subscription_cleanup procedure i masterdatabasen for at droppe de abonnementer, der udløb eller var inaktive i lang tid. Som standard udføres denne procedure én gang om dagen.

Replikationsforsinkelse og sporingstokens

Replikeringsforsinkelse er den tid, der kræves af replikeringsprocessen for at spore eventuelle ændringer, der sker på publicerede artikler fra udgiverdatabasen, indtil den er leveret med succes til abonnenten via distributør.

Replikationsforsinkelse måles i millisekunder. Målværdien på 0 (realtidsreplikation) til en meget lav værdi (ideelle tilfælde). Det er en af ​​de vigtigste foranstaltninger til at overvåge replikeringsydelsen.

Vi kan verificere replikeringsforsinkelsen ved hjælp af replikeringsmonitor eller de dedikerede sp_replcounters procedure.

Siden replikeringsmonitor har opdateringen rate, kan der være små afvigelser fra de observerede værdier. For at overvinde de små afvigelser, mens vi beregner replikationsforsinkelsen, kommer Tracer Tokens os til undsætning.

Klik på Tracer Tokens fanen (se billedet ovenfor) for at sende et nyt sæt testkommandoer fra udgiveren. Mål det derefter, hvornår det når distributørdatabasen, og hvornår det blev sendt til abonnentdatabasen. Klik på Indsæt sporingsmiddel for at sende sporing-tokens fra Publisher-databasen:

Når registreringerne er modtaget i Subscriber, kan vi spore den samlede replikeringsforsinkelse for vores nuværende opsætning. I vores tilfælde er det 9 sekunder:4 sekunder fra udgiver til distributør og 5 sekunder fra distributør til abonnent.

Tablediff Utility

Tablediff-værktøj(tablediff.exe) vil blive installeret i stien C:\Program Files\Microsoft SQL Server\130\COM når vi har installeret replikeringskomponenterne.

TableDiff-værktøjet sammenligner 2 tabeller for ikke-konvergens. Det betyder, at vi kan sammenligne 2 tabeller og identificere forskellene mellem dem. Derefter synkroniserer den destinationstabellen sammenlignet med kildetabellen ved at generere dedikerede INSERT/UPDATE/DELETE scripts. Flere detaljer er tilgængelige i den officielle dokumentation.

Da SQL Server Transactional Replication er ligeglad med manuelle ændringer på abonnentdatabasen, kan dette hjælpeprogram hjælpe med at synkronisere denne slags tabeller efter behov. Den har dog ikke en guide eller brugergrænseflade – du kan kun få adgang til den via kommandoprompten eller fra batchfiler.

Andre værktøjer kan gøre sammenligning og synkronisering enklere. dbForge Compare Bundle til SQL Server kontrollerer for uoverensstemmelser i databaserne, og specifikke tabeller identificerer og analyserer dem. Det genererer også de nødvendige scripts for at synkronisere dem. Det tilbyder en visuel grænseflade og en masse muligheder for at køre opgaverne hurtigt og ligetil.

SQL Server Agent Alerts

Alle nøglekomponenter, der er relateret til replikeringsagenter, ligger som jobs under SQL Server Agent-jobbene. Derfor er det afgørende at overvåge, hvordan SQL Server Agent-job fungerer kontinuerligt for at sikre, at replikering fungerer uden problemer. De mest almindelige problemer er nedenfor:

• Problem med tilladelser til at udføre et hvilket som helst af replikeringsagentjobbene
• Problem med tilladelser til at udføre et hvilket som helst af replikeringsvedligeholdelsesjobene.
• Problem med tilladelser til at få adgang til udgiver eller distribution eller abonnentdatabase.
• SQL Server Agent er ikke konfigureret til at starte automatisk ved genstart af serveren.
• Flere andre replikeringsrelaterede dataproblemer som konflikter, manglende data og så videre.

Det er derfor, vi bør have en ordentlig varslingsmekanisme på plads til at underrette DBA eller en anden person om ethvert problem med det samme.

For at advare DBA'er eller andre personer i tilfælde af jobfejl eller fejl, bør vi konfigurere Database Mail til at sende e-mail-advarsler. Det giver DBA mulighed for at reagere med det samme og løse problemet. Vi vil diskutere, hvordan du konfigurerer Database Mail og Alerts i en separat artikel senere.

Mens du konfigurerer replikering, opretter SQL Server som standard nedenstående sæt af advarsler. Du kan nemt konfigurere dem til de nødvendige kriterier. Det sikrer også, at der sendes meddelelser til påkrævede personer for øjeblikkelig handling.

Konklusion

Tak, fordi du gik igennem endnu en stor artikel om replikering. Jeg håber, det hjalp med at afklare det interne i Transactional Replikation og detaljerne om distributionsdatabase, replikeringsagenter og selvstændige programmer, der er ansvarlige for disse. Vi har også identificeret replikeringsforsinkelsen, advarsler og sporingstokens.

Nu kan vi dykke dybere og lære, hvordan vi behandler og løser replikeringsproblemer professionelt. Hold øje med den næste artikel!