Databasreplikering är tekniken för att distribuera data från den primära servern till sekundära servrar. Replikering fungerar på Master-slave-konceptet där Master-databasen distribuerar data till en eller flera slavservrar. Replikering kan ställas in mellan flera SQL Server-instanser på samma server, ELLER kan den ställas in mellan flera databasservrar inom samma eller geografiskt åtskilda datacenter.
Det finns två huvudsakliga fördelar med att använda SQL Server-replikering:
- Med hjälp av replikering kan vi få nästan realtidsdata som kan användas för rapporteringsändamål. Till exempel, när du vill separera den skrivintensiva OLTP-belastningen på en server och läsintensiv belastning på en annan server, kan du ställa in replikering för att hålla data synkroniserad på båda servrarna.
- Den andra fördelen är att du kan schemalägga replikeringen så att den körs på en viss tid. Om du till exempel vill att rapportservern ska innehålla data för den slutförda dagen kan du schemalägga replikeringsögonblicksbilden därefter. Vi behöver inte skriva ytterligare logik för att hantera aktuella data.
Replikering erbjuder mycket flexibilitet. Med hjälp av replikering kan vi filtrera bort raderna och även replikera delmängden av data i vilken tabell som helst. Vi kan ändra replikerad data eller replikera bara uppdatera och infoga och ignorera borttagningarna. Vi kan också replikera data från ett annat databassystem som Oracle.
Replikeringskomponenter
Det finns sju kärnkomponenter i SQL Server Replication. Följande är listan:
- Utgivare.
- Distributör.
- Prenumerant.
- Artiklar.
- Publikation.
- Push-prenumeration.
- Pull-prenumeration.
Följande är detaljerna:
Artiklar
En artikel är ett databasobjekt, till exempel en SQL-tabell, eller en lagrad procedur. Som jag nämnde ovan, med hjälp av replikering, kan vi filtrera data, eller så kan vi replikera den valda tabellkolumnen, därför betraktas tabellkolumner eller -rader som artiklar.
Publikation
Artiklar kan inte kopieras förrän de blir en del av publikationen. Publicering är gruppen av Artiklar/Databasobjekt. Den representerar också datamängden som kommer att replikeras av SQL Server.
Utgivare
Publisher innehåller en huvuddatabas som har de data som behöver publiceras. Den bestämmer vilken data som ska distribueras över alla abonnenter.
Distributör
Distributören är bryggan mellan utgivare och prenumerant. Distributören samlar all publicerad data och håller den tills den skickas över alla prenumeranter. Det är en bro mellan utgivare och prenumerant. Det stöder flera utgivare och abonnentkoncept. Det är inte obligatoriskt att konfigurera distributör på en separat SQL-instans eller en separat server. Om vi inte konfigurerar det kan utgivaren fungera som distributör. Organisationer som har storskalig replikering kan konfigurera distributör på ett separat system.
Prenumeranter
Abonnenten är slutet på källan eller destinationen till vilken data eller replikerad publikation kommer att överföras. I replikering finns det en utgivare, den kan ha flera prenumeranter.
Push-prenumeration
I en push-prenumeration uppdaterar utgivaren data till prenumeranten. I ett Push-abonnemang är abonnenten passiv. Förlaget skickar artiklar eller publikationer till alla sina prenumeranter. Baserat på organisationens krav, när du skapar replikeringsguiden, på skärmen, kan du välja vilken prenumeration som ska användas. Transaktionsreplikering och peer-to-peer-replikering använder Push-prenumerationen för att upprätthålla datatillgängligheten i realtid.
Pull-prenumeration
I en Pull-prenumeration begär alla prenumeranter ny data eller uppdaterad data från dess utgivare. I ett pull-abonnemang kan vi kontrollera att vilka data eller dataändringar som behövs för prenumeranter. Det är användbart när vi inte behöver de ändrade uppgifterna omedelbart.
replikeringstyper
SQL Server stöder tre replikeringstyper:
- Transaktionsreplikering.
- Snapshot Replikering.
- Slå samman replikering.
Transaktionsreplikering
Transaktionsreplikering, eventuella schemaändringar, dataändringar som sker i utgivardatabasen kommer att replikeras på prenumerantdatabasen. Närhelst någon uppdatering, radering eller infogning sker i utgivardatabasen, spåras ändringarna och dessa ändringar skickas till abonnentdatabaserna. Transaktionell replikering skickar endast en begränsad mängd data över ett nätverk. Dessutom är förändringar nästan i realtid, därför kan den användas för att sätta upp DR-webbplatsen, eller den kan användas för att skala ut rapporteringsverksamheten. Transaktionsreplikering är idealisk för följande situationer:
- När du vill ställa in ett system där ändringar som görs på utgivaren ska tillämpas på prenumeranter omedelbart.
- Utgivaren har hög låg INSERT, UPDATES och DELETES.
- När du vill ställa in heterogen replikering, utgivare eller prenumeranter för icke-SQL Server-databaser, som Oracle.
När några ändringar görs i utgivardatabasen loggas ändringar i en loggfil på utgivaredatabasen. Distributör/Utgivares webbplats, två jobb kommer att skapas.
- Snapshot Agent :Snapshot agent jobb genererar ögonblicksbilden av schemat, data för de objekt som vi vill replikera eller publicera. Filer av ögonblicksbilden kan sparas på Publisher-servern eller nätverksplatsen. När vi initierar replikeringen för första gången skapar den en ögonblicksbild och tillämpar den på alla prenumeranter. Snapshot-agenten förblir inaktiv tills den utlöses manuellt eller schemalagd att köras på en viss tid.
- Log Reader Agent :Loggläsaragentjobb körs kontinuerligt. Den läser ändringarna (INSERT, UPPDATERINGAR och DELETES) som inträffade från utgivardatabasens transaktionslogg och skickar dem till en distributionsagent.
- Distributionsagent :När ändringar har hämtats från Log Reader-agenten skickar distributionsagenten alla ändringar till prenumeranterna.
När vi konfigurerar transaktionsreplikering utför den följande aktiviteter
- Det initieras genom att ta den första ögonblicksbilden av publikationsdata och databasobjekt och ögonblicksbilden som tillämpas på prenumeranter.
- Loggläsaragenten övervakar kontinuerligt utgivarens T-logg och om några ändringar inträffar skickar den dem till distributören eller direkt till prenumeranter.
Följande bild representerar hur transaktionsreplikering fungerar:
Fördelar:
- Transaktionsreplikering kan användas som en standby SQL-server, eller så kan den användas för lastbalansering eller separering av rapporteringssystem och OLTP-system.
- Utgivarserver replikerar data till abonnentserver med låg latens.
- Med hjälp av transaktionsreplikering kan replikering på objektnivå implementeras.
- Transaktionsreplikering kan tillämpas när du har färre data att skydda, och du bör ha en snabb dataåterställningsplan.
Nackdelar:
- När replikeringen har etablerats, gäller inte schemaändringarna på utgivaren på prenumerantservern. Vi måste göra dessa ändringar manuellt genom att skapa en ny ögonblicksbild och tillämpa den på prenumeranter.
- Om vi ändrar servrarna måste vi konfigurera om replikeringen.
- Om transaktionsreplikering används som en DR-installation måste vi göra failover manuellt.
Snapshot Replikering
Snapshot-replikering genererar en komplett bild/snapshot av publiceringen enligt ett definierat schema och skickar ögonblicksbildfilerna till prenumeranter. När ögonblicksbildreplikering inträffar kommer destinationsdata att ersättas med en ny ögonblicksbild. Snapshot-replikering är det bästa alternativet när data är mindre flyktiga. Till exempel är mastertabeller som City, Zipcode, Pincode de bästa kandidaterna för replikering av ögonblicksbilder.
När du konfigurerar ögonblicksbildreplikering definieras följande viktiga komponenter:
- Snapshot Agent :Den skapar en komplett bild av schema och data som definierats i publikationen och skickar den till distributören. Snapshot-agenten förblir inaktiv tills den utlöses manuellt ELLER schemalagd att köras på en viss tid.
- Distributörsagent :Den skickar ögonblicksbildfilerna till prenumeranter och tillämpar schema och data genom att ersätta det befintliga.
Replikering av ögonblicksbilder utför följande aktiviteter:
- På det definierade schemat placerar ögonblicksbildsagenten ett delat lås på schemat och data som ska publiceras.
- Hela ögonblicksbilden av publicerad data kopierad till distributören. Snapshot agent skapar tre filer
- Fil till skapat databasschema över publicerade data.
- BCP-fil för att exportera data inom SQL-tabeller
- Indexera filer för att exportera indexdata.
- När filerna har skapats släpper ögonblicksbildagenten delade lås på publicerad data och data.
- Distributörsagenter startar och ersätter prenumerantschemat och data med filer som skapats av ögonblicksbildsagenten.
Följande bild illustrerar hur ögonblicksbildreplikering fungerar.
Fördelar
- Snapshot-replikering är mycket enkel att ställa in. Om data inte ändras ofta är replikering av ögonblicksbilder ett mycket lämpligt alternativ.
- Du kan styra när data ska skickas. Till exempel en huvudtabell som har en hög datavolym, men som ändras mindre ofta än vad du kan replikera data när trafiken är låg.
Nackdelar
- Önblicksbild som genereras av ögonblicksbildsagenten innehåller ändrad och oförändrad publicerad data, därför kan ögonblicksbilden som sänds över nätverket ge latens och påverka andra operationer.
- När data ökar, ökar storleken på ögonblicksbilden och det tar längre tid att skapa och distribuera ögonblicksbilden till prenumeranter.
Slå samman replikering
Sammanslagningsreplikering kan användas när vi behöver hantera ändringar på flera servrar och dessa ändringar måste konsolideras.
När vi konfigurerar sammanslagningsreplikering kommer följande komponenter att skapas:
- Snapshot Agent :Snapshot-agent genererar den första ögonblicksbilden av publikationsdata och databasobjekt. När ögonblicksbilden har skapats kommer den att distribueras till alla prenumeranter.
- Slå samman agent :Merge agent ansvarar för att lösa konflikter mellan utgivare och prenumeranter. Eventuella konflikter löses genom sammanslagningsagenten som använder konfliktlösning. Beroende på hur du konfigurerade konfliktlösningen löses konflikterna av sammanslagningsagenten.
När vi konfigurerar sammanslagningsreplikering utför den följande aktiviteter:
- Det initieras genom att ta en ögonblicksbild av publikationsdata och databasobjekt och en ögonblicksbild som appliceras på prenumeranter.
- När du konfigurerar sammanslagningsreplikering skapas utlösare för utgivare och prenumeranter. Utlösare ansvarar för att hålla reda på efterföljande ändringar och tabelländringar på utgivare och prenumeranter.
- När utgivare och prenumeranter ansluter till nätverket synkroniseras ändringar av datarader och schemaändringar med varandra. När du slår samman ändringarna av utgivaren och prenumeranterna löser sammanslagningsagenten konflikterna baserat på villkoren som definieras i sammanslagningsagenten.
Sammanslagningsreplikering används i server-till-klient-miljöer, och det är idealiskt för situationer där prenumeranter behöver hämta data från utgivaren, göra ändringar offline och sedan synkronisera ändringar med utgivaren och andra prenumeranter.
Det kan finnas praktiska situationer där samma rad ändras av olika förlag och prenumeranter. Vid den tidpunkten kommer sammanslagningsagenten att titta på vilken konfliktlösning som definieras och göra ändringar i enlighet med detta.
SQL Server identifierar unikt en kolumn med hjälp av en globalt unik identifierare för varje rad i en publicerad tabell. Om tabellen redan har en unik identifierarkolumn använder SQL Server automatiskt den kolumnen. Annars kommer den att lägga till en rowguid-kolumn i tabellen och skapa ett index baserat på kolumnen.
Utlösare kommer att skapas på de publicerade tabellerna på både utgivare och prenumeranter. De används för att spåra ändringarna baserat på rad- eller kolumnändringarna.
Följande bild illustrerar hur sammanslagningsreplikering fungerar:
Fördelar:
- Detta är det enda sättet att lyckas konsolidera ändringar på flera serverdata.
Nackdelar:
- Det tar mycket tid att replikera och synkronisera båda ändarna.
- Det är låg konsekvens eftersom många parter måste synkroniseras.
- Det kan uppstå konflikter vid sammanslagning av replikering om samma rader påverkas i mer än en prenumerant och utgivare. Det kan fixas med hjälp av konfliktlösningen, men det gör replikeringsinställningarna mer komplicerade.
T-SQL-kod för att granska replikeringskonfigurationen
Jag har konfigurerat ögonblicksbildreplikeringen och transaktionsreplikeringen på två instanser av min dator. Med hjälp av SQL Dynamic Management (DMV) kan vi kontrollera replikeringskonfigurationen. För att granska konfigurationen av replikering kan vi använda T-SQL-kod. Skriptkoden fyller i följande:
- Namn på prenumerantdatabas.
- Utgivarens namn.
- Prenumerationstyp.
- Utgivarens databas.
- Replikeringsagentens namn.
Nedan är skriptet:
SELECT DistributionAgent.subscriber_db [Subscriber DB], DistributionAgent.publication [PUB Name], RIGHT(LEFT(DistributionAgent.NAME, Len(DistributionAgent.NAME) - ( Len( DistributionAgent.id) + 1 )), Len(LEFT( DistributionAgent.NAME, Len(DistributionAgent.NAME) - ( Len( DistributionAgent.id) + 1 ))) - ( 10 + Len(DistributionAgent.publisher_db) + ( CASE WHEN DistributionAgent.publisher_db = 'ALL' THEN 1 ELSE Len( DistributionAgent.publication) + 2 END ) )) [SUBSCRIBER], ( CASE WHEN DistributionAgent.subscription_type = '0' THEN 'Push' WHEN DistributionAgent.subscription_type = '1' THEN 'Pull' WHEN DistributionAgent.subscription_type = '2' THEN 'Anonymous' ELSE Cast(DistributionAgent.subscription_type AS VARCHAR) END ) [Subscrition Type], DistributionAgent.publisher_db + ' - ' + Cast(DistributionAgent.publisher_database_id AS VARCHAR) [Publisher Database], DistributionAgent.NAME [Pub - DB - Publication - SUB - AgentID] FROM distribution.dbo.msdistribution_agents DistributionAgent WHERE DistributionAgent.subscriber_db <> 'virtual'
Följande är resultatet:
Sammanfattning
I den här artikeln har jag förklarat:
- Grunden och fördelarna med replikering och dess komponenter.
- Transaktionsreplikering.
- Snapshot replikering.
- Slå samman replikering.