Det finns en app för högskolebokhandel online där många studenter kan köpa böcker. Varje gång en elev loggar in visar den en lista med förslag baserat på deras tidigare köphistorik. SQL Servern som lagrar kunddata finns i Seattle, men dessa studenter loggar in från hela världen. Därför kan prestanda bli lidande och de som är längre bort i WAN kan uppleva en tidsfördröjning för frågor.
Istället för att eleverna som är längre bort lider av långsamma sidladdningstider, kan replikering användas för att kopiera och underhålla databasobjekt på flera platser och synkronisera senare så att konsistensen bibehålls. Varje webbplats behåller den del av databasen som innehåller de data som är mest relevanta för dem och som används mest. Nu kan varje elev köpa böcker på webbplatsen och data synkroniseras senare.
Så fungerar datareplikering
Det finns flera serverkomponenter och de tar på sig olika roller för att implementera replikering. En utgivarroll är en databasinstans där datakällan finns och den innehåller objekt som är utformade som replikeringsartiklar. Dessa artiklar grupperas och publiceras i en publikation så att data replikeras som en enhet. Förlaget kan ha flera publikationer.
En distributörsroll är en databasinstans som innehåller distributionsdatabaserna. Varje utgivare mappas till en enda distributionsdatabas som lagrar de replikerade data från utgivaren som ska skickas till abonnenten. Distributören skulle kunna ställas in som en lokal distributör, vilket innebär att en enda serverinstans kan tjäna både utgivarens och distributörens roll. Om en distributör är konfigurerad på separata servrar kallas den för en fjärrdistributör.
En prenumerantroll är den eller de instanser som tar emot replikerad data genom att prenumerera på publikationerna. Prenumeranten är inte begränsad och är berättigad att ta emot data från flera utgivare, och objekten kan uppdateras beroende på replikeringstyp. Om tillämpligt skulle utgivaren ta emot dessa ändringar från prenumeranten och återpublicera uppgifterna.
I allmänhet får abonnenten ändringar av data på två sätt:genom push-prenumeration eller pull-prenumeration. Skillnaden är vilken serverkomponent som utför uppdateringarna. Med push pushar distributören eller uppdaterar abonnentdatabasen direkt. Med pull checkar abonnenten in hos distributören för att se om det har skett några ändringar, och den kommer att utföra uppdateringen själv.
Tre typer av datareplikering
För att implementera replikering används flera agenter för att utföra de jobb som är associerade med att kopiera ändringar, hålla reda på ändringar och distribuera data. Vilka medel som behövs beror på vilken typ av replikering som används. Det finns tre huvudtyper av replikering.
1. Replikering av ögonblicksbilder
Snapshot-replikering är den enklaste typen av datareplikering och används om data inte ändras lika ofta eller om små mängder data behöver replikeras. Till exempel, om det finns tabeller som inte uppdateras mycket, kan Snapshot Agents användas för att kopiera hela databasen en gång eller upprepade gånger enligt ett schema. Sedan är en distributionsagent ansvarig för att överföra dessa filer till abonnenten.
Denna teknik kräver lite underhåll eftersom det som distribueras är en ögonblicksbild av data vid ett specifikt ögonblick. Det finns heller inget behov av att övervaka förändringar eftersom varje gång en abonnent får en uppdatering skriver den över hela kopian av data.
Tyvärr kan kopiering av en hel databas bidra till hög latens eller fler väntetider än önskvärt. Att generera ögonblicksbilder kräver att man håller lås på objekt. Det är inte bekvämt om data ändras ofta och sannolikt påverkar prestandan – till exempel om utgivaren har massor av infogning, uppdatering och radering.
Förutom att använda ögonblicksbildsagenterna för att skapa ögonblicksbilderna, drar transaktionsreplikationer också fördel av Log Reader-agenter som körs hos distributören. Log Reader Agent läser transaktionsloggar för publicistdatabasen och levererar endast de markerade ändringarna istället för att vänta på en hel databas. Detta ger flexibilitet eftersom det ger dig utrymme att bestämma hur mycket av databasen som ska publiceras (t.ex. en kolumn). Sedan flyttar distributionsagenten transaktionerna till abonnenterna, och där den körs kommer den att rymma push- respektive pull-prenumerationsstrategierna.
2. Transaktionsreplikering
Standard transaktionell replikering innebär att data hos abonnenten är skrivskyddad. Det finns dock olika publikationstyper som gör att ändringar kan göras hos abonnenten. Om dessa ändringar görs kan de skickas tillbaka till utgivaren för ompublicering. Queue Reader Agent används för dubbelriktad transaktionsreplikering, och den läser ändringar från kön och tillämpar dem hos utgivaren.
Transaktionsreplikering är mycket fördelaktigt i en server-till-server-miljö där ändringar kan göras hos utgivaren och hos abonnenten i realtid – till exempel realtidsdata om vilka flygningar som för närvarande är tillgängliga för ett flygbolag. Det är inte meningsfullt att använda ögonblicksbildreplikering i det här fallet eftersom uppdateringar vanligtvis synkroniseras en gång per dag eller enligt ett schema.
3. Sammanfoga replikering
Sammanslagningsreplikering är som transaktionsreplikering, men det gör att uppdateringar hos både abonnenten och utgivaren kan slås samman. Många prenumeranter kan gå offline, göra uppdateringar av data vid olika tidpunkter och sedan gå tillbaka online och synkronisera dessa ändringar senare.
Denna typ av replikering kommer sannolikt att användas i server-till-klient-miljöer som mobila klienter. Liksom ögonblicksbild och transaktionsreplikering skapas den första ögonblicksbilden av ögonblicksbildsagenten, men sedan kommer sammanslagningsagenten att spåra ändringarna och lösa konflikter med utlösare. Om flera prenumeranter uppdaterar samma rader kan de orsaka problem. Därför måste konfliktlösning redovisas.