SQL Server Transactionele Replicatie Internals – Deel 2

SQL Server Transactionele Replicatie is een van de meest gebruikte replicatietechnieken die wordt gebruikt om gegevens over meerdere bestemmingen te kopiëren of te distribueren. In het vorige artikel hebben we SQL Server-replicatie, soorten replicatie en de basisinternals besproken over hoe de transactionele replicatie werkt. Nu gaan we dieper in op Advanced Internals van hoe SQL Server Transactionele Replicatie werkt.

Transactionele replicatie-architectuur

Voordat we beginnen, raad ik je aan om je kennis op te frissen met mijn vorige artikel hier.

Laten we beginnen met het bekijken van de SQL Server Transactional Replication Architecture die hieronder wordt weergegeven in de Microsoft-documentatie.

In de Uitgeversdatabase , maak een Publicatie bestaande uit de lijst met Artikelen (Tafels , Beelden , etc.) die u moet repliceren naar de Abonnee databank. Zodra de artikelen zijn ingeschakeld voor replicatie, worden alle wijzigingen in deze artikelen gemarkeerd voor replicatie in de Transactielogboeken van de Publisher-database.

SQL Server Transactionele Replicatie kan worden geïnitialiseerd vanaf de Publisher naar Distributeur en dan naar de Abonnee database via Snapshot Agent of Vol Back-ups . De Snapshot Agent kan de Initialisatie . uitvoeren via de Replicatieconfiguratiewizard . De volledige back-up wordt alleen ondersteund via T-SQL-instructies.

De Log Reader-agent scant het transactielogboek van de Publisher-database om de bijgehouden wijzigingen te detecteren die zijn gemarkeerd voor replicatie. Het negeert andere wijzigingen die zijn vastgelegd in de transactielogboeken en kopieert gegevenswijzigingen van het transactielogboek naar de distributiedatabase.

De distributiedatabase kan zich in Publisher of Subscriber bevinden, of in een ander onafhankelijk SQL Server-exemplaar. Let op de volgende dingen:

• Log Reader Agent draait continu vanaf de Distributor Server om te scannen op nieuwe opdrachten die zijn gemarkeerd voor replicatie. Als u echter niet continu wilt werken en in plaats daarvan volgens een schema wilt werken, kunnen we de Log Reader Agent SQL-taak wijzigen die wordt gemaakt.
• Log Reader Agent haalt alle records die zijn gemarkeerd voor replicatie in batches op uit het transactielogboek en stuurt deze naar de distributiedatabase.
• Log Reader Agent haalt alleen Toegezegde transacties op uit het Transactielogboek van Publisher Database. Dus langlopende query's op de Publisher-database kunnen rechtstreeks van invloed zijn op replicatie terwijl deze wacht tot de actieve transactie is voltooid.

De distributieagent haalt alle niet-gedistribueerde nieuwe opdrachten op uit de distributiedatabase en past deze toe op de abonnementendatabase via Push of Trek Mechanisme .

• Push-abonnement – de distributeur neemt het eigendom over om wijzigingen van de Distributiedatabase toe te passen op de Abonnee.
• Pull-abonnement – ​​ de Abonnee database neemt het eigendom over om wijzigingen op te halen van de Distributiedatabase naar de Abonnee.

Zodra de records met succes zijn gedistribueerd van Distributie naar de abonneedatabase, worden ze gemarkeerd als Gedistribueerd en ook gemarkeerd voor verwijdering uit de distributiedatabase .

Een van de belangrijkste taken voor replicatieonderhoud is de Distribution Clean Up :De Distributietaak wordt elke 10 minuten uitgevoerd om gedistribueerde records uit de Distributiedatabase te verwijderen om de grootte van de Distributiedatabase onder controle te houden.

Daarom is ons doel voor het huidige artikel om de volgende onderwerpen te onderzoeken:

• Distributiedatabase
• Replicatie-agenten
  • Momentopname-agent
  • Log Reader-agent
  • Distributieagent
• Replicatie Agent-profielen
• Replicatie onderhoudstaken
• Replicatielatentie en tracertokens
• TableDiff-hulpprogramma
• SQL Server Agent-waarschuwingen

SQL Server-distributiedatabase

Een distributiedatabase is een systeemdatabase die is gemaakt tijdens het configureren van Replicatie. Het is het hart van replicatie omdat het grootste deel van het proces uit een distributiedatabase loopt.

Vanwege de aard van de distributiedatabase kunnen we er slechts beperkte bewerkingen op uitvoeren, zoals back-up en herstel. We kunnen het niet direct laten vallen zoals gebruikersdatabases.

Voor een enorme database met veel gegevens die worden gerepliceerd, moeten we enkele speciale maatregelen nemen om de doorvoerprestaties van de replicatie te verbeteren:

Standaard wordt de distributiedatabase gemaakt op het standaard installatiepad geconfigureerd in SQL Server . Als het niet is geconfigureerd, wordt het gemaakt op de C : drive of in de SQL Server Installation-mappen. We raden u aan de distributiedatabase naar een snellere opslag/schijf te verplaatsen om de prestaties te verbeteren.

De initiële bestandsgrootte en Autogroei van de distributiedatabase wordt ingesteld volgens de instellingen voor Initial File Size en Autogrowth van de modeldatabase. Configureer de initiële bestandsgrootte naar een betere waarde, zoals 10 GB in het geval van de transactioneel drukke databasereplicatie. De Autogrowth-eigenschappen mogen maximaal 512 MB of 1 GB zijn voor zowel gegevens- als logbestanden. Dan zal er niet veel fragmentatie zijn in de gegevens- en logbestanden.

Configureer de Dagelijks of Routine back-uptaken om de distributiedatabase op te nemen voor referentiedoeleinden of om problemen op te lossen in geval van beschadiging of verlies van gegevens.

Configureer de Dagelijkse indexreorganisatie of Onderhoud banen om de distributiedatabase op te nemen. De database omvat enorme gegevensinvoer in de MSrepl_transactions en MSrepl_commands tabellen.

Opmerking:continu pollen op deze 2 tabellen en eruit VERWIJDEREN nadat de gegevens met succes naar de abonneedatabase zijn verzonden, verhoogt het risico op fragmentatie. Het opnieuw opbouwen van deze tabellen op een geplande basis kan de prestaties van de distributiedatabase verbeteren.

Klik met de rechtermuisknop op Replicatie om de kenmerken van de distributiedatabase met betrekking tot replicatie te bekijken en te wijzigen. > Distributeureigenschappen :

Klik op het ellips knop aan de rechterkant om meer details te zien over de afzonderlijke opties die worden vermeld.

Let op, het wijzigen van parameters kan van invloed zijn op de prestaties van de distributiedatabase. Voer daarom wijzigingen pas door nadat u alle parameters die u wilt wijzigen zorgvuldig hebt geëvalueerd.

Transactiebehoud specificeert hoeveel gegevens in de distributiedatabase moeten worden bewaard. De minimum- en maximumwaarden kunnen in uren of dagen worden gespecificeerd.

De waarde voor het bewaren van transacties die is ingesteld op 0 uur, geeft aan dat records die eenmaal zijn gerepliceerd naar de abonneedatabase, kunnen worden verwijderd uit de distributiedatabase. Als u deze waarde verhoogt, wordt de distributiedatabase groter. We moeten het dus dienovereenkomstig plannen.

Geschiedenisbehoud specificeert de bewaarperiode voor het opslaan van de prestatiegeschiedenisgegevens van de transactiereplicatie. Standaard is dit 48 uur.

Om een distributiedatabase te laten vallen , we moeten Publicatie uitschakelen geassocieerd met die specifieke distributiedatabase en laat deze vervolgens vallen met een van de twee methoden. Een daarvan is een combinatie van Publiceren uitschakelen en de wizard Distributie. Een andere gebruikt sp_dropdistributor of sp_dropdistributiondb procedures. De Wizard gebruikt intern deze 2 procedures om Distributie uit te schakelen en de distributiedatabase te verwijderen.

SQL Server-replicatieagenten

Replicatieagenten zijn zelfstandige programma's die verantwoordelijk zijn voor het bijhouden van gegevenswijzigingen van Publisher en het doorgeven van die wijzigingen aan Distributeur- en Abonneedatabases. Ze worden uitgevoerd als SQL Server Agent-taken.

Laten we eerst eens kijken naar de locatie van deze zelfstandige programma's.

Om Replicatie te configureren, hebben we de Replicatiecomponenten . nodig geïnstalleerd via het SQL Server-installatieprogramma. Als u klaar bent, kunnen we de aan de Replicatieagent gerelateerde zelfstandige programma's zien die beschikbaar zijn in het installatiepad:

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

In mijn geval is de versie van SQL Server-versie 2016. Daarom is het minder dan 130 in het pad.

Voor elke Replication Agent kunnen we het respectievelijke beschikbare standalone programma zien:

• DISTRIB.exe – Distributieagent
• Logread.exe – Logboeklezer-agent
• Qrdrsvc.exe – Wachtrijlezer Service Agent
• Replmerg.exe – Replicatieagent samenvoegen
• Snapshot.exe – Snapshot-agent
• Tablediff.exe – Hulpprogramma om tabellen te vergelijken. We kunnen later in dit artikel op meer details ingaan.

Nu we weten waarvoor deze zelfstandige programma's verantwoordelijk zijn en waar ze zich bevinden, kunnen we begrijpen hoe ze worden uitgevoerd via SQL Server Agent Jobs.

Aangezien we te maken hebben met SQL Server Transactionele Replicatie, zullen we de taken Snapshot Agent, Log Reader Agent en Distribution Agent doorlopen (dezelfde logica is van toepassing op alle andere agents).

Momentopname-agent

De Snapshot Agent wordt uitgevoerd vanaf de server die de distributiedatabase bevat. Het bereidt het schema en de initiële gegevens voor van alle artikelen die zijn opgenomen in een publicatie op een uitgever, maakt de snapshotbestanden aan in de snapshotmap en legt de synchronisatiedetails vast in de distributiedatabase.

Uit de distributie MSSnapshot_agents tabel, kunnen we de SQL Server Agent-taak identificeren die de Snapshot Agent-activiteiten uitvoert. Elke publicatie omvat een speciale SQL Server Agent-taak die moet zorgen voor de Snapshot Agent-verantwoordelijkheden.

Vouw SQL Server-agent uit en open de hierboven genoemde taaknaam. Het toont de details en de Categorie naam – REPL-Momentopname

Klik op de Stap om activiteiten te zien die zijn uitgevoerd door de Snapshot-agent.

Klik op een individuele stap om de informatie over de Snapshot-agenttaak te bekijken.

Stap 1 registreert een item in de geschiedenistabel telkens wanneer de Snapshot-agent start met behulp van de sp_MSadd_snapshot_history procedure.

De tabel met de geschiedenis van de details die door de Snapshot-agent zijn uitgevoerd, is de MSsnapshot_history tabel in de distributiedatabase.

Het komt overeen met de Status momentopname agent bekijken dialoogvenster.

Ga naar Stap 2 – Agent uitvoeren . Het zal de taak Snapshot Agent starten .

Onder het Commando , konden we geen T-SQL-statements of -query's vinden. Er waren slechts enkele parameters vermeld. Het antwoord ligt dus in het gemarkeerde gedeelte van de bovenstaande afbeelding. Het laat zien dat het Job Step Type is Snapshot replicatie waarmee het snapshot.exe standalone programma . wordt gestart om de verantwoordelijkheden van de Snapshot Agent uit te voeren.

Raadpleeg dit MSDN-artikel voor meer informatie over snapshot.exe. We zullen ook in detail treden terwijl we de replicatie-gerelateerde problemen later oplossen.

Ten slotte gaan we naar Stap 3 – de laatste taakstap. Het registreert onverwachte afsluitingen van Agent Jobs en logt ze uit.

Log Reader-agent

Telkens wanneer de publicatie in een database wordt geconfigureerd, worden alle wijzigingen die in die artikelen plaatsvinden, gemarkeerd voor replicatie in het transactielogboek. De Log Reader Agent leest die gegevenswijzigingen via logread.exe en slaat ze op in de Distributiedatabase via 2 afzonderlijke processen:

• Transactielogboeken lezen – het gebruikt de sp_replcmds uitgebreide opgeslagen procedure om te scannen op gegevenswijzigingen van de uitgever. Aangezien deze opgeslagen procedure verwijst naar DLL-bestanden, wordt niet duidelijk gemaakt hoe Microsoft logbestanden precies leest. We kunnen echter ongedocumenteerde functies proberen, zoals fn_dblog() en fn_dump_dblog() om te begrijpen hoe het transactielogboekbestand werkt.

• Schrijven naar distributiedatabase – het gebruikt de sp_MSadd_replcmds opgeslagen procedure in de distributiedatabase om de binaire gegevens te schrijven die zijn gelezen uit de transactielogboeken van de uitgeversdatabase. Het schrijft de transactiedetails naar de MSrepl_transactions tabel en individuele commando's naar de MSrepl_commands tafel.

Er is slechts één Log Reader SQL Server Agent-taak beschikbaar voor elke gepubliceerde database. U kunt de naam identificeren zoals hieronder weergegeven:

Vouw de SQL Server Agent uit en open de bovenstaande Log Reader Agent-taak om de stappen te bekijken. Het toont de taak Сategorie onder Replicatielogboeklezer.

Klik op Stappen om individuele stappen te zien die door de Log Reader Agent zijn uitgevoerd. Net als bij de taak Snapshot Agent, kunnen we 3 equivalente stappen zien voor de taak Log Reader Agent.

Stap 1 roept de sp_MSadd_logreader_history . aan procedure om de opstartstatusgeschiedenisberichten van de Log Reader Agent te loggen in de MSlogreader_history tafel.

Stap 2 start het Log Reader Agent-proces met behulp van het logread.exe zelfstandige programma .

U kunt meer details over logread.exe vinden in het betreffende MSDN-artikel. Later zullen we ook de kritieke configuratieparameters van de Log Reader Agent onderzoeken.

Stap 3 legt een abrupte afsluiting van de Log Reader Agent-taak vast.

Distributieagent

Distribution Agent (DISTRIB.exe) werd gebruikt door Transactional and Snapshot Replication om de initiële Snapshot-bestanden toe te passen en om beschikbare lopende transacties van de Distribution-database op te hogen of toe te passen op de Abonnee-database.

Deze Agent draait vanaf de Distributor Server voor de Push Abonnementen en de Abonnee Server voor de Pull Abonnementen. Om de naam te vinden van de SQL Server Agent-taak die de verantwoordelijkheden van de distributieagent uitvoert, kunnen we de specifieke query uitvoeren zoals hieronder wordt weergegeven:

Vouw de SQL Server Agent-taak uit en open deze om meer informatie en de categorie te zien die is toegewezen aan de replicatiedistributie.

Klik op Stappen – u zult de stappen zien die vergelijkbaar zijn met de eerder weergegeven stappen van de Snapshot en Log Reader Agent-taken.

Stap 1 roept de sp_MSadd_distribution_history . op procedure om de opstartstatusgeschiedenisberichten van de Log Reader Agent te loggen in de MSdistribution_history tafel.

Stap 2 start het Distribution Agent-proces (DISTRIB.exe) met de standaardparameters.

Raadpleeg het MSDN-artikel voor meer informatie over DISTRIB.exe. Verder zullen we in de volgende artikelen de kritieke configuratieparameters van de distributieagent doornemen.

Stap 3 legt details vast over het abrupt afsluiten van de taak van de distributieagent.

Replicatie-agentprofielen

Van de Distributeureigenschappen , kunnen we de optie krijgen om de Replicatie Agent-profielen . te bekijken . Laat de agentprofielen op de standaardwaarden staan ​​en wijzig ze alleen als dat nodig is voor het oplossen van problemen.

Klik op Standaardinstellingen profiel om de standaardwaarden te bekijken die zijn geconfigureerd voor alle replicatieagenten die beschikbaar zijn op de server.

Selecteer de Distributieagenten en klik op het ellips knop naast het Standaard agentprofiel om de geconfigureerde waarden te zien. Zie de afbeelding hieronder:

Bekijk het Standaard agentprofiel van de Snapshot-agenten lezer Agent:

Standaard agentprofiel voor de Log Reader Agent:

Replicatie onderhoudstaken

Naast replicatieagenten hebben we replicatieonderhoudstaken .

Dit zijn SQL Server Agent-taken die zijn gemaakt tijdens het configureren van de SQL Server-transactiereplicatie. Ze zijn beschikbaar om ervoor te zorgen dat de transactiereplicatie correct werkt.

Sommige taken op het gebied van replicatieonderhoud zijn essentieel voor transactionele replicatie. Laten we ze eens bekijken.

• Distributie opschonen: Distributie – voert de sp_MSdistribution_cleanup . uit procedure om replicatiecommando's te verwijderen uit de MSrepl_transactions en MSrepl_commands tafels. Het opschonen van de distributiedatabase vindt plaats nadat opdrachten met succes naar de abonneedatabase zijn verzonden op basis van de waarde voor de transactieretentieperiode die in de distributiedatabase is geconfigureerd. Standaard wordt deze taak elke 10 minuten uitgevoerd op de distributiedatabase. Wijzig deze waarden pas na een grondige evaluatie.

• Agent Geschiedenis opschonen:distributie – voert de sp_MShistory_cleanup . uit procedure in de distributiedatabase om historische records op te schonen die ouder zijn dan de bewaarperiode voor geschiedenis die in die database is geconfigureerd. Standaard is het geconfigureerd voor 48 dagen en wordt het elke 10 minuten uitgevoerd. Als u deze waarden wilt wijzigen, overweeg dan alle aspecten zorgvuldig.

• Verlopen Abonnement opruimen – voert de sp_expired_subscription_cleanup . uit procedure in de hoofddatabase om die abonnementen te verwijderen die zijn verlopen of lange tijd inactief waren. Standaard wordt deze procedure eenmaal per dag uitgevoerd.

Replicatielatentie en tracertokens

Replicatievertraging is de tijd die het replicatieproces nodig heeft om eventuele wijzigingen in gepubliceerde artikelen uit de uitgeversdatabase bij te houden totdat deze met succes aan de abonnee worden geleverd via de distributeur.

Replicatielatentie wordt gemeten in milliseconden. De doelwaarde van 0 (realtime replicatie) tot een zeer lage waarde (ideale gevallen). Het is een van de belangrijkste maatregelen om de replicatieprestaties te controleren.

We kunnen de replicatielatentie verifiëren met behulp van Replication Monitor of de speciale sp_replcounters procedure.

Sinds de Replicatiemonitor heeft de refresh kunnen er kleine afwijkingen zijn van de waargenomen waarden. Om de kleine afwijkingen te overwinnen tijdens het berekenen van de replicatielatentie, komen Tracer Tokens ons te hulp.

Klik op de Tracer-tokens tabblad (zie de afbeelding hierboven) om een ​​nieuwe set testopdrachten van de Publisher te verzenden. Meet het vervolgens wanneer het de Distributeur-database bereikt en wanneer het naar de Abonnee-database is verzonden. Klik op Insert Tracer om tracer-tokens te verzenden vanuit de Publisher-database:

Zodra de records met succes zijn ontvangen in de abonnee, kunnen we de totale replicatielatentie voor onze huidige configuratie volgen. In ons geval is dat 9 seconden:4 seconden van uitgever naar distributeur en 5 seconden van distributeur naar abonnee.

Tablediff-hulpprogramma

Tablediff-hulpprogramma(tablediff.exe) wordt geïnstalleerd in het pad C:\Program Files\Microsoft SQL Server\130\COM zodra we de replicatiecomponenten hebben geïnstalleerd.

Het hulpprogramma TableDiff vergelijkt 2 tabellen voor niet-convergentie. Het betekent dat we 2 tabellen kunnen vergelijken en de verschillen daartussen kunnen identificeren. Vervolgens synchroniseert het de Destination-tabel in vergelijking met de Source-tabel door speciale INSERT/UPDATE/DELETE-scripts te genereren. Meer details zijn beschikbaar in de officiële documentatie.

Aangezien SQL Server Transactionele Replicatie niet geïnteresseerd is in handmatige wijzigingen in de abonneedatabase, kan dit hulpprogramma helpen bij het synchroniseren van dit soort tabellen wanneer en wanneer dat nodig is. Het heeft echter geen wizard of gebruikersinterface - u kunt het alleen openen via de opdrachtprompt of vanuit batchbestanden.

Andere tools kunnen vergelijking en synchronisatie eenvoudiger maken. De dbForge Compare Bundle voor SQL Server controleert op discrepanties in de databases en specifieke tabellen identificeert en analyseert deze. Het genereert ook de nodige scripts om ze te synchroniseren. Het biedt een visuele interface en een heleboel opties om de taken snel en eenvoudig uit te voeren.

SQL Server Agent-waarschuwingen

Alle belangrijke componenten met betrekking tot replicatieagenten bevinden zich als taken onder de SQL Server Agent-taken. Daarom is het van cruciaal belang om voortdurend te controleren hoe SQL Server Agent-taken werken om ervoor te zorgen dat replicatie zonder problemen werkt. De meest voorkomende problemen staan ​​hieronder:

• Machtigingsprobleem bij het uitvoeren van een van de Replication Agent-taken
• Machtigingsprobleem bij het uitvoeren van een van de onderhoudstaken voor replicatie.
• Machtigingsprobleem voor toegang tot Publisher of distributie of abonneedatabase.
• SQL Server Agent niet geconfigureerd om automatisch te starten bij herstart van de server.
• Verschillende andere gegevensproblemen met replicatie, zoals conflicten, ontbrekende gegevens, enzovoort.

Daarom moeten we een goed waarschuwingsmechanisme hebben om de DBA of een andere persoon onmiddellijk op de hoogte te stellen van een probleem.

Om DBA's of andere mensen te waarschuwen in geval van mislukte taken of fouten, moeten we de Database Mail configureren om e-mailwaarschuwingen te verzenden. Het stelt de DBA in staat om meteen te reageren en het probleem op te lossen. We zullen later in een apart artikel bespreken hoe je de Database Mail en Alerts configureert.

Tijdens het configureren van replicatie maakt SQL Server standaard de onderstaande set waarschuwingen. U kunt ze eenvoudig configureren voor de vereiste criteria. Het zorgt er ook voor dat er meldingen worden verzonden naar de vereiste personen voor onmiddellijke actie.

Conclusie

Bedankt voor het doornemen van weer een enorm artikel over Replicatie. Ik hoop dat het heeft geholpen om de interne aspecten van Transactionele Replicatie te verduidelijken en de details over de Distributiedatabase, Replicatieagenten en Standalone Programma's die daarvoor verantwoordelijk zijn. We hebben ook de replicatielatentie, waarschuwingen en tracertokens geïdentificeerd.

Nu kunnen we dieper duiken en leren hoe we replicatieproblemen professioneel kunnen behandelen en oplossen. Houd ons in de gaten voor het volgende artikel!