Verbessern der Verfügbarkeit und der Skalierbarkeit
In vielen Anwendungen ist es unerlässlich, sowohl eine höhere Verfügbarkeit als auch eine höhere Leseskalierbarkeit zu bieten. Die Replikation kann als wichtiger Teil dazu beitragen, diese beiden Aspekte sicherzustellen. Bei einigen Anwendungen wird möglicherweise darauf abgezielt, entweder die Verfügbarkeit oder die Skalierbarkeit durch die Replikation zu verbessern. Wenn Sie einen dieser Bereiche in Augenschein nehmen möchten, ziehen Sie eines der folgenden Szenarien zurate:
In den folgenden Diagrammen werden zwei Anwendungen dargestellt, die die Replikation nutzen, um die Verfügbarkeit und die Skalierbarkeit zu erhöhen. In beiden Fällen handelt es sich bei den drei Datenbanken in den Diagrammen um Peers: Sie enthalten identische Schemas und Daten. Die Schreibaktivitäten für diese Datenbanken müssen partitioniert werden: Wenn die Datenbank einen Produktkatalog enthält, könnten Sie beispielsweise Aktualisierungen an die erste Datenbank für Produktnamen richten, die mit A–I beginnen, die zweite Datenbank für J–R und die dritte Datenbank für S–Z. Die Aktualisierungen werden dann auf die anderen Datenbanken repliziert.
Das erste Diagramm stellt eine Konfiguration dar, in der jeder Web- und Anwendungsserver Daten von einem bestimmten Cacheserver verwendet. Lesevorgänge und Aktualisierungen für einen bestimmten Benutzer fließen an einen bestimmten Anwendungsserver und anschließend an einen bestimmten Cacheserver. Da der Anwendungsserver den Cache direkt aktualisiert, ist kein zentraler Quellserver erforderlich. Aktualisierungen auf den einzelnen Caches werden an die anderen Caches weitergegeben.
.gif "Skalieren der Leseaktivität mit Replikation")
Das zweite Diagramm zeigt drei geografisch voneinander getrennte Server, zwischen denen Daten fließen, sodass jeder der Server Leseanforderungen unterstützt und die Verfügbarkeit verbessert wird.
.gif "Peer-zu-Peer-Replikation an verteilte Standorte")
Beispiel mit Adventure Works Cycles
Adventure Works Cycles ist eine zum Demonstrieren von Datenbankkonzepten und -szenarien erfundene Produktionsfirma. Weitere Informationen finden Sie unter AdventureWorks2008R2-Beispieldatenbanken.
Adventure Works Cycles verfügt über viele Niederlassungen auf der ganzen Welt, beispielsweise in Los Angeles, London und Taipei Kundenbestellungsinformationen werden an den einzelnen Standorten gesammelt und auf andere Standorte repliziert.
Bestellungsinformationen können von sämtlichen Standorten aus gelesen werden. Wenn demzufolge die Niederlassung in London eine erhebliche Leseaktivität verzeichnet, können interne Anwendungen einen Teil dieser Aktivitäten auf die anderen beiden Niederlassungen verteilen.
Falls ein Server in der Londoner Niederlassung wartungsbedingt ausfällt, können Aufträge beispielsweise nach wie vor von einem anderen Standort abgerufen werden, und die Mitarbeiter in der Londoner Niederlassung können weiterhin Daten lesen und eingeben. Wenn der Server in London wieder online ist, werden die Änderungen, die während seiner Ausfallzeit empfangen wurden, an den Londoner Server weitergegeben, damit dieser wieder aktuell ist.
Allgemeine Anforderungen für dieses Szenario
Anwendungen, die aus Gründen der Skalierbarkeit und Verfügbarkeit die Replikation verwenden, haben folgende Anforderungen, die eine geeignete Replikationslösung erfüllen muss:
Das System sollte zulassen, dass Änderungen, die an einem beliebigen Server erfolgen, auf alle anderen Server repliziert werden.
Das System muss die Transaktionskonsistenz aufrechterhalten.
Das System sollte geringe Latenzzeiten bieten: Aktualisierungen an einem Server müssen die anderen Server schnell erreichen.
Das System sollte einen hohen Durchsatz sicherstellen: Es sollte in der Lage sein, die Replikation vieler Transaktionen durchzuführen.
Die Replikationsverarbeitung sollte nur einen minimalen Aufwand mit sich bringen.
Typ der für dieses Szenario zu verwendenden Replikation
Microsoft SQL Server verwendet ein Modell, das sich auf Abläufe aus dem Verlagswesen stützt, um die Komponenten des Replikationssystems zu beschreiben. Zu den Komponenten zählen der Verleger, der Abonnent, Veröffentlichungen und Artikel sowie Abonnements.
In den oben stehenden Diagrammen sind alle Cacheserver Verleger und Abonnenten. Alle Daten der replizierten Datenbank auf sämtlichen Servern sind in der Veröffentlichung enthalten, wobei jede Datentabelle einen Artikel darstellt (Artikel können auch andere Datenbankobjekte sein, z. B. gespeicherte Prozeduren). Jeder Server ist ein Abonnent der Veröffentlichung der anderen Server und erhält Schemas und Daten als Abonnement. Weitere Informationen zu den Komponenten des Systems finden Sie unter Das Replikationsveröffentlichungsmodell (Übersicht).
SQL Server bietet verschiedenen Replikationstypen für unterschiedliche Anwendungsanforderungen: die Snapshotreplikation, die Transaktionsreplikation und die Mergereplikation. Für dieses Szenario wird am besten die Peer-to-Peer-Transaktionsreplikation implementiert, da hiermit die im vorherigen Abschnitt aufgeführten Anforderungen am besten erfüllt werden. Weitere Informationen zur Peer-to-Peer-Transaktionsreplikation finden Sie unter Peer-zu-Peer-Transaktionsreplikation.
.gif "Hinweis") Hinweis |
|---|
Wenn die Anwendung erfordert, dass Änderungen an einer bestimmten Zeile an mehreren Knoten gleichzeitig vorgenommen werden, können Datenkonflikte auftreten. Verwenden Sie in diesem Fall die Mergereplikation, die sich gut zum Lösen von Konflikten eignet. Weitere Informationen zur Mergereplikation finden Sie unter Mergereplikation (Übersicht). |
Die Transaktionsreplikation erfüllt die Hauptanforderungen für dieses Szenario programmbedingt:
Änderungen können an einem beliebigen Server vorgenommen werden
Transaktionskonsistenz
Geringe Latenzzeit
Hoher Durchsatz
Minimaler Aufwand
Die Peer-to-Peer-Option für die Transaktionsreplikation ermöglicht es den Servern, dieselben Daten zu veröffentlichen und zu abonnieren. Alle Knoten in einer Peer-to-Peer-Topologie sind Peers. Das heißt, jeder Knoten veröffentlicht und abonniert dieselben Schemas und Daten. Änderungen (Einfügungen, Aktualisierungen und Löschungen) können an allen Knoten vorgenommen und anschließend auf alle anderen Knoten repliziert werden.
Schritte für die Implementierung dieses Szenarios
Für die Implementierung dieses Szenarios müssen Sie zunächst Veröffentlichungen und Abonnements erstellen und die einzelnen Abonnements initialisieren. Weitere Informationen finden Sie hier:
SQL Server Management Studio: Vorgehensweise: Konfigurieren der Peer-to-Peer-Transaktionsreplikation (SQL Server Management Studio)
Replikationsprogrammierung mit Transact-SQL: Vorgehensweise: Konfigurieren der Peer-to-Peer-Transaktionsreplikation (Replikationsprogrammierung mit Transact-SQL)
Nachdem die Abonnements initialisiert wurden und Daten zwischen den Peers fließen, müssen Sie möglicherweise folgende Themen zurate ziehen, um Informationen zu allgemeinen Verwaltungs- und Überwachungsaufgaben zu erhalten: