Er is een online universiteitsboekwinkel-app waar veel studenten boeken kunnen kopen. Elke keer dat een student inlogt, wordt een lijst met suggesties weergegeven op basis van zijn eerdere aankoopgeschiedenis. De SQL Server die de klantgegevens opslaat staat in Seattle, maar deze studenten loggen vanuit de hele wereld in. Daarom kunnen de prestaties eronder lijden en kunnen degenen die verder weg zijn over het WAN een vertraging oplopen bij het uitvoeren van vragen.
In plaats van dat de leerlingen die verder weg zijn last hebben van langzame laadtijden van pagina's, kan replicatie worden gebruikt om database-objecten op meerdere sites te kopiëren en te onderhouden en later te synchroniseren, zodat de consistentie behouden blijft. Elke site houdt het gedeelte van de database bij dat de gegevens bevat die voor hen het meest relevant zijn en die het meest worden gebruikt. Nu kan elke student boeken kopen op de website en de gegevens worden later gesynchroniseerd.
Hoe gegevensreplicatie werkt
Er zijn verschillende servercomponenten en deze nemen verschillende rollen op zich om replicatie te implementeren. Een uitgeversrol is een database-instantie waarin de bron van de gegevens zich bevindt en deze bevat objecten die zijn ontworpen als replicatieartikelen. Deze artikelen worden gegroepeerd en gepubliceerd in een publicatie, zodat de gegevens als een eenheid worden gerepliceerd. De uitgever kan meerdere publicaties hebben.
Een distributeursrol is een database-instantie die de distributiedatabases bevat. Elke uitgever is toegewezen aan een enkele distributiedatabase waarin de gerepliceerde gegevens van de uitgever zijn opgeslagen die aan de abonnee moeten worden doorgegeven. De distributeur kan worden opgezet als een lokale distributeur, wat betekent dat een enkele serverinstantie kan dienen in de rol van zowel de uitgever als de distributeur. Als een distributeur op afzonderlijke servers is geconfigureerd, wordt dit een externe distributeur genoemd.
Een abonneerol is de instantie(s) die de gerepliceerde gegevens ontvangt door zich te abonneren op de publicaties. De abonnee is niet beperkt en komt in aanmerking voor het ontvangen van gegevens van meerdere uitgevers, en de objecten kunnen worden bijgewerkt, afhankelijk van het replicatietype. Indien van toepassing zou de uitgever deze wijzigingen van de abonnee ontvangen en de gegevens opnieuw publiceren.
In het algemeen ontvangt de abonnee op twee manieren wijzigingen in de gegevens:via push-abonnement of pull-abonnement. Het verschil zit hem in welk serveronderdeel de updates uitvoert. Met push pusht of actualiseert de distributeur de abonneedatabase. Met pull checkt de abonnee in bij de distributeur om te zien of er wijzigingen zijn en voert de update zelf uit.
Drie soorten gegevensreplicatie
Om replicatie te implementeren, worden verschillende agenten gebruikt om de taken uit te voeren die verband houden met het kopiëren van wijzigingen, het bijhouden van wijzigingen en het distribueren van de gegevens. Welke agents nodig zijn, hangt af van het type replicatie dat wordt gebruikt. Er zijn drie hoofdtypen replicatie.
1. Snapshot-replicatie
Snapshot-replicatie is het eenvoudigste type gegevensreplicatie en wordt gebruikt als de gegevens niet zo vaak worden gewijzigd of als kleine hoeveelheden gegevens moeten worden gerepliceerd. Als er bijvoorbeeld tabellen zijn die niet vaak worden bijgewerkt, kunnen Snapshot Agents worden gebruikt om de hele database eenmalig of herhaaldelijk volgens een schema te kopiëren. Vervolgens is een distributieagent verantwoordelijk voor het overdragen van deze bestanden naar de abonnee.
Deze techniek vereist weinig onderhoud omdat wat wordt gedistribueerd een momentopname is van de gegevens op een bepaald moment in de tijd. Het is ook niet nodig om te controleren op wijzigingen, want elke keer dat een abonnee een update ontvangt, wordt de volledige kopie van de gegevens overschreven.
Helaas kan het kopiëren van een hele database bijdragen aan een hoge latentie of meer wachttijden dan wenselijk. Het genereren van snapshots vereist het vasthouden van vergrendelingen op objecten. Het is niet handig als gegevens vaak worden gewijzigd en de prestaties waarschijnlijk worden beïnvloed, bijvoorbeeld als de uitgever veel invoeg-, bijwerk- en verwijderactiviteiten heeft.
Naast het gebruik van de Snapshot Agents om de snapshots te maken, maken transactionele replicaties ook gebruik van Log Reader Agents die bij de distributeur draaien. De Log Reader Agent leest transactielogboeken van de uitgeversdatabase en levert alleen de gemarkeerde wijzigingen in plaats van te wachten op een hele database. Dit biedt flexibiliteit omdat het u de ruimte geeft om te beslissen hoeveel van de database u wilt publiceren (bijvoorbeeld een kolom). Vervolgens verplaatst de distributieagent de transacties naar de abonnees, en waar het wordt uitgevoerd, zal het respectievelijk de push- en pull-abonnementsstrategieën accommoderen.
2. Transactiereplicatie
Standaard transactionele replicatie houdt in dat de gegevens bij de abonnee alleen-lezen zijn. Er zijn echter verschillende publicatietypes die het mogelijk maken om wijzigingen aan te brengen bij de abonnee. Als deze wijzigingen zijn aangebracht, kunnen ze worden teruggestuurd naar de uitgever om opnieuw te publiceren. De Queue Reader Agent wordt gebruikt voor bidirectionele transactionele replicatie en leest wijzigingen uit de wachtrij en past deze toe bij de uitgever.
Transactiereplicatie is zeer nuttig in een server-naar-server-omgeving waar wijzigingen kunnen worden aangebracht bij de uitgever en bij de abonnee in realtime, bijvoorbeeld realtime gegevens met betrekking tot welke vluchten momenteel beschikbaar zijn voor een luchtvaartmaatschappij. Het heeft in dit geval geen zin om snapshot-replicatie te gebruiken, omdat updates doorgaans eenmaal per dag of volgens een schema worden gesynchroniseerd.
3. Replicatie samenvoegen
Samenvoegreplicatie is vergelijkbaar met transactiereplicatie, maar hiermee kunnen updates bij zowel de abonnee als de uitgever worden samengevoegd. Veel abonnees kunnen offline gaan, de gegevens op verschillende tijdstippen bijwerken en vervolgens weer online gaan en die wijzigingen later synchroniseren.
Dit type replicatie wordt waarschijnlijk gebruikt in server-naar-client-omgevingen, zoals mobiele clients. Net als snapshot- en transactiereplicatie, wordt de eerste snapshot gemaakt door de Snapshot Agent, maar vervolgens zal de Merge Agent de wijzigingen volgen en conflicten met triggers oplossen. Als meerdere abonnees dezelfde rijen bijwerken, kunnen ze een probleem veroorzaken. Daarom moet er rekening worden gehouden met conflictoplossing.