Es gibt eine Online-College-Buchladen-App, in der viele Studenten Bücher kaufen können. Jedes Mal, wenn sich ein Schüler anmeldet, wird eine Liste mit Vorschlägen basierend auf seiner bisherigen Kaufhistorie angezeigt. Der SQL-Server, auf dem die Kundendaten gespeichert sind, befindet sich in Seattle, aber diese Studenten melden sich von überall auf der Welt an. Daher kann die Leistung darunter leiden, und diejenigen, die sich weiter entfernt über das WAN befinden, können eine Zeitverzögerung bei Abfragen erfahren.
Anstatt dass die Schüler, die weiter entfernt sind, unter langsamen Seitenladezeiten leiden müssen, kann die Replikation verwendet werden, um Datenbankobjekte an mehreren Standorten zu kopieren und zu verwalten und später zu synchronisieren, damit die Konsistenz gewahrt bleibt. Jede Website behält den Teil der Datenbank, der die Daten enthält, die für sie am relevantesten sind und am häufigsten verwendet werden. Jetzt kann jeder Schüler Bücher auf der Website kaufen, und die Daten werden später synchronisiert.
Funktionsweise der Datenreplikation
Es gibt mehrere Serverkomponenten, die unterschiedliche Rollen übernehmen, um die Replikation zu implementieren. Eine Herausgeberrolle ist eine Datenbankinstanz, in der sich die Quelle der Daten befindet, und sie enthält Objekte, die als Replikationsartikel konzipiert sind. Diese Artikel werden zusammengefasst und in einer Publikation veröffentlicht, sodass die Daten als Einheit repliziert werden. Der Herausgeber kann mehrere Veröffentlichungen haben.
Eine Verteilerrolle ist eine Datenbankinstanz, die die Verteilungsdatenbanken enthält. Jeder Herausgeber wird einer einzelnen Verteilungsdatenbank zugeordnet, in der die replizierten Daten des Herausgebers gespeichert werden, die an den Abonnenten weitergegeben werden sollen. Der Verteiler könnte als lokaler Verteiler eingerichtet werden, was bedeutet, dass eine einzelne Serverinstanz sowohl die Rolle des Herausgebers als auch des Verteilers übernehmen kann. Wenn ein Verteiler auf separaten Servern konfiguriert ist, wird er als Remote-Verteiler bezeichnet.
Eine Abonnentenrolle ist die Instanz(en), die die replizierten Daten empfängt, indem sie die Veröffentlichungen abonniert. Der Abonnent ist nicht eingeschränkt und berechtigt, Daten von mehreren Herausgebern zu empfangen, und die Objekte können je nach Replikationstyp aktualisiert werden. Gegebenenfalls würde der Herausgeber diese Änderungen vom Abonnenten erhalten und die Daten erneut veröffentlichen.
Im Allgemeinen erhält der Abonnent Änderungen an den Daten auf zwei Wegen:durch Push-Abonnement oder Pull-Abonnement. Der Unterschied besteht darin, welche Serverkomponente die Aktualisierungen durchführt. Mit Push pusht oder aktualisiert der Distributor die Abonnentendatenbank direkt. Beim Pull meldet sich der Abonnent beim Distributor, um zu sehen, ob es Änderungen gegeben hat, und dieser führt die Aktualisierung selbst durch.
Drei Arten der Datenreplikation
Um die Replikation zu implementieren, werden mehrere Agenten verwendet, um die Jobs auszuführen, die mit dem Kopieren von Änderungen, dem Nachverfolgen von Änderungen und dem Verteilen der Daten verbunden sind. Welche Agenten benötigt werden, hängt vom verwendeten Replikationstyp ab. Es gibt drei Haupttypen der Replikation.
1. Snapshot-Replikation
Die Snapshot-Replikation ist die einfachste Art der Datenreplikation und kommt zum Einsatz, wenn sich die Daten nicht so oft ändern oder kleine Datenmengen repliziert werden müssen. Wenn es beispielsweise Tabellen gibt, die nicht häufig aktualisiert werden, können Snapshot-Agenten verwendet werden, um die gesamte Datenbank einmal oder wiederholt nach einem Zeitplan zu kopieren. Dann ist ein Verteilungsagent dafür verantwortlich, diese Dateien an den Abonnenten zu übertragen.
Diese Technik ist wartungsarm, da eine Momentaufnahme der Daten zu einem bestimmten Zeitpunkt verteilt wird. Außerdem besteht keine Notwendigkeit, Änderungen zu überwachen, da jedes Mal, wenn ein Abonnent eine Aktualisierung erhält, die gesamte Kopie der Daten überschrieben wird.
Leider kann das Kopieren einer gesamten Datenbank zu einer hohen Latenz oder mehr Wartezeiten als erwünscht beitragen. Das Generieren von Snapshots erfordert das Halten von Sperren für Objekte. Es ist nicht praktisch, wenn Daten häufig geändert werden und sich wahrscheinlich auf die Leistung auswirken – zum Beispiel, wenn der Herausgeber viele Einfüge-, Aktualisierungs- und Löschaktivitäten hat.
Neben der Verwendung der Snapshot-Agenten zum Erstellen der Snapshots nutzen Transaktionsreplikationen auch die Protokolllese-Agenten, die auf dem Verteiler ausgeführt werden. Der Log Reader Agent liest Transaktionsprotokolle der Publisher-Datenbank und liefert nur die markierten Änderungen, anstatt auf eine gesamte Datenbank zu warten. Dies bietet Flexibilität, da Sie entscheiden können, wie viel von der Datenbank veröffentlicht werden soll (z. B. eine Spalte). Dann verschiebt der Verteilungsagent die Transaktionen zu den Abonnenten, und dort, wo er ausgeführt wird, werden die Push- bzw. Pull-Abonnementstrategien berücksichtigt.
2. Transaktionsreplikation
Die standardmäßige Transaktionsreplikation impliziert, dass die Daten beim Abonnenten schreibgeschützt sind. Es gibt jedoch verschiedene Veröffentlichungstypen, die Änderungen beim Abonnenten ermöglichen. Wenn diese Änderungen vorgenommen werden, können sie zur erneuten Veröffentlichung an den Herausgeber zurückgesendet werden. Der Warteschlangenlese-Agent wird für die bidirektionale Transaktionsreplikation verwendet und liest Änderungen aus der Warteschlange und wendet diese beim Herausgeber an.
Die Transaktionsreplikation ist sehr vorteilhaft in einer Server-zu-Server-Umgebung, in der Änderungen beim Herausgeber und beim Abonnenten in Echtzeit vorgenommen werden können – beispielsweise Echtzeitdaten in Bezug darauf, welche Flüge für eine Fluggesellschaft derzeit verfügbar sind. Es ist in diesem Fall nicht sinnvoll, die Snapshot-Replikation zu verwenden, da Updates normalerweise einmal täglich oder nach einem Zeitplan synchronisiert werden.
3. Mergereplikation
Die Mergereplikation ist wie die Transaktionsreplikation, ermöglicht jedoch das Zusammenführen von Aktualisierungen sowohl beim Abonnenten als auch beim Herausgeber. Viele Abonnenten können offline gehen, die Daten zu unterschiedlichen Zeiten aktualisieren und dann wieder online gehen und diese Änderungen später synchronisieren.
Diese Art der Replikation wird wahrscheinlich in Server-zu-Client-Umgebungen wie mobilen Clients verwendet. Wie bei der Snapshot- und Transaktionsreplikation wird der anfängliche Snapshot vom Snapshot-Agent erstellt, aber dann verfolgt der Merge-Agent die Änderungen und löst Konflikte mit Triggern. Wenn mehrere Abonnenten dieselben Zeilen aktualisieren, können sie ein Problem verursachen. Daher muss eine Konfliktlösung berücksichtigt werden.
