Der er en online college boghandel app, hvor mange studerende kan købe bøger. Hver gang en elev logger på, viser den en liste over forslag baseret på deres tidligere købshistorik. SQL Serveren, der gemmer kundedataene, er i Seattle, men disse studerende logger på fra hele verden. Derfor kan ydeevnen lide, og de, der er længere væk på tværs af WAN'et, kan opleve en tidsforsinkelse for forespørgsler.
I stedet for at eleverne, der er længere væk, lider af langsomme sideindlæsningstider, kan replikering bruges til at kopiere og vedligeholde databaseobjekter på flere websteder og synkronisere senere, så konsistensen bevares. Hvert websted opbevarer den del af databasen, der indeholder de data, der er mest relevante for dem og oftest brugt. Nu kan hver elev købe bøger på hjemmesiden, og dataene synkroniseres senere.
Sådan fungerer datareplikering
Der er flere serverkomponenter, og de påtager sig forskellige roller for at implementere replikering. En udgiverrolle er en databaseforekomst, hvor kilden til dataene findes, og den indeholder objekter, der er designet som replikeringsartikler. Disse artikler er grupperet sammen og publiceret i en publikation, så dataene replikeres som en enhed. Forlaget kan have flere publikationer.
En distributørrolle er en databaseinstans, der indeholder distributionsdatabaserne. Hver udgiver er knyttet til en enkelt distributionsdatabase, der gemmer de replikerede data fra udgiveren, som skal videregives til abonnenten. Distributøren kunne konfigureres som en lokal distributør, hvilket betyder, at en enkelt serverinstans kan fungere i rollerne som både udgiver og distributør. Hvis en distributør er konfigureret på separate servere, omtales den som en fjerndistributør.
En abonnentrolle er den eller de instanser, der modtager de replikerede data ved at abonnere på publikationerne. Abonnenten er ikke begrænset og er berettiget til at modtage data fra flere udgivere, og objekterne kan blive opdateret afhængigt af replikeringstypen. Hvis det er relevant, vil udgiveren modtage disse ændringer fra abonnenten og genudgive dataene.
Generelt modtager abonnenten ændringer til dataene på to måder:gennem push-abonnement eller pull-abonnement. Forskellen er, hvilken serverkomponent der udfører opdateringerne. Med push pusher distributøren eller opdaterer abonnentdatabasen direkte. Med pull tjekker abonnenten ind hos distributøren for at se, om der er ændringer, og den vil selv udføre opdateringen.
Tre typer datareplikering
For at implementere replikering bruges flere agenter til at udføre de job, der er forbundet med kopiering af ændringer, holde styr på ændringer og distribuere data. Hvilke midler der er nødvendige afhænger af den anvendte type replikation. Der er tre hovedtyper af replikering.
1. Snapshot-replikering
Snapshot-replikering er den enkleste type datareplikering og bruges, hvis dataene ikke ændres så ofte, eller hvis små mængder data skal replikeres. For eksempel, hvis der er tabeller, der ikke bliver opdateret meget, så kan Snapshot Agents bruges til at kopiere hele databasen én gang eller gentagne gange i henhold til en tidsplan. Derefter er en distributionsagent ansvarlig for at overføre disse filer til abonnenten.
Denne teknik kræver lidt vedligeholdelse, fordi det, der bliver distribueret, er et øjebliksbillede af dataene på et bestemt tidspunkt. Det er heller ikke nødvendigt at overvåge for ændringer, fordi hver gang en abonnent modtager en opdatering, overskriver den hele kopien af dataene.
Desværre kan kopiering af en hel database bidrage til høj latenstid eller flere ventetider end ønskeligt. Generering af snapshots kræver, at man holder låse på objekter. Det er ikke praktisk, hvis data bliver ændret ofte og sandsynligvis vil påvirke ydeevnen – for eksempel hvis udgiveren har masser af indsættelses-, opdaterings- og sletningsaktiviteter.
Ud over at bruge Snapshot-agenterne til at oprette snapshots, udnytter transaktionsreplikationer også Log Reader-agenter, der kører hos distributøren. Log Reader Agent læser transaktionslogfiler for udgiverdatabasen og leverer kun de markerede ændringer i stedet for at vente på en hel database. Dette giver fleksibilitet, fordi det giver dig plads til at bestemme, hvor meget af databasen du vil publicere (f.eks. en kolonne). Derefter flytter distributionsagenten transaktionerne til abonnenterne, og hvor den kører, vil den rumme henholdsvis push- og pull-abonnementsstrategierne.
2. Transaktionel replikering
Standard transaktionsreplikering indebærer, at dataene hos abonnenten er skrivebeskyttet. Der er dog forskellige publikationstyper, der gør det muligt at foretage ændringer hos abonnenten. Hvis disse ændringer foretages, kan de videresendes tilbage til udgiveren for at genudgive dem. Kølæseragenten bruges til tovejs transaktionsreplikering, og den læser ændringer fra køen og anvender dem hos udgiveren.
Transaktionel replikering er meget fordelagtig i et server-til-server-miljø, hvor ændringer kan foretages hos udgiveren og hos abonnenten i realtid - for eksempel realtidsdata vedrørende hvilke flyvninger, der i øjeblikket er tilgængelige for et flyselskab. Det giver ikke mening at bruge snapshot-replikering i dette tilfælde, fordi opdateringer typisk synkroniseres én gang om dagen eller i henhold til en tidsplan.
3. Flet replikering
Fletreplikering er ligesom transaktionsreplikering, men det tillader opdateringer hos både abonnenten og udgiveren at blive flettet sammen. Mange abonnenter kan gå offline, foretage opdateringer til dataene på forskellige tidspunkter og derefter gå online igen og synkronisere disse ændringer senere.
Denne type replikering vil sandsynligvis blive brugt i server-til-klient-miljøer såsom mobile klienter. Ligesom snapshot og transaktionsreplikering oprettes det indledende snapshot af Snapshot Agenten, men derefter vil Merge Agent spore ændringerne og løse konflikter med triggere. Hvis flere abonnenter opdaterer de samme rækker, kan de forårsage et problem. Derfor skal der redegøres for konfliktløsning.