• Artikel

Peer-to-Peer-Transaktionsreplikation

Peer-to-Peer-Replikation bietet eine skalierbare Lösung mit hoher Verfügbarkeit, da Kopien der Daten auf mehreren Serverinstanzen verwaltet werden, die auch als Knoten bezeichnet werden. Auf der Grundlage der Transaktionsreplikation aufbauend, gibt die Peer-to-Peer-Replikation transaktionskonsistente Änderungen fast in Echtzeit weiter. Dies macht Anwendungen möglich, die skalierbare Lesevorgänge voraussetzen, weil die Leseanforderungen von Clients über mehrere Knoten verteilt werden können. Da die Knoten die Daten fast in Echtzeit übernehmen, bietet die Peer-to-Peer-Replikation Datenredundanz, die die Verfügbarkeit der Daten erhöht.

Betrachten Sie eine Webanwendung. Sie kann von Peer-to-Peer-Replikation auf folgende Weise profitieren:

  • Katalogabfragen und andere Lesevorgänge werden über mehrere Knoten verteilt. Dadurch bleibt die Leistung auch dann konsistent, wenn sich die Anzahl der Lesevorgänge erhöht.

  • Wenn einer der Knoten des Systems ausfällt, können auf der Anwendungsebene die Schreibvorgänge für diesen Konten an einen anderen Knoten umgeleitet werden. Dadurch wird die Verfügbarkeit gewährleistet.

  • Muss ein Knoten gewartet oder das gesamte System aktualisiert werden, kann jeder Knoten einzeln offline geschaltet und wieder in das System eingefügt werden, ohne dass die Verfügbarkeit der Anwendung darunter leidet.

Zwar ermöglicht die Peer-to-Peer-Replikation die Skalierung von Lesevorgängen, doch bleibt die Schreibgeschwindigkeit in der Topologie ähnlich der für einen einzelnen Knoten. Dies kommt daher, weil letztlich alle Einfügungen, Aktualisierungen und Löschungen an alle Knoten weitergegeben werden. Die Replikation erkennt, wenn eine Änderung auf einen bestimmten Knoten angewendet wurde, und verhindert, dass Änderungen die Knoten mehrmals durchlaufen. Wir raten aus den folgenden Gründen dringend, Schreibvorgänge für eine Zeile nur an einem Knoten auszuführen:

  • Wird eine Zeile an mehr als einem Knoten geändert, kann es zu einem Konflikt kommen, oder die Aktualisierung kann sogar verloren gehen, wenn die Zeile an andere Knoten weitergegeben wird.

  • Bei der Replizierung von Änderungen verstreicht immer eine gewisse Latenzzeit. Bei Anwendungen, die sofort die neuesten Änderungen erkennen müssen, kann der dynamische Lastenausgleich über mehrere Knoten problematisch werden.

Die Peer-to-Peer-Replikation in SQL Server 2008 führt die Option ein, die Konflikterkennung für eine gesamte Peer-to-Peer-Topologie zu aktivieren. Diese Option hilft, den Problemen vorzubeugen, die sich aus nicht erkannten Konflikten, einschließlich inkonsistentem Verhalten von Anwendungen und verlorenen Aktualisierungen ergeben. Standardmäßig wird, wenn diese Option aktiviert ist, eine konfliktverursachende Änderung als ein schwerwiegender Fehler betrachtet, der zu einem Fehler des Verteilungs-Agents führt. Bei einem Konflikt verbleibt die Topologie so lange in einem inkonsistenten Zustand, bis der Konflikt manuell gelöst und die Datenkonsistenz in der Topologie wiederhergestellt wurde. Weitere Informationen finden Sie unter Konflikterkennung bei der Peer-to-Peer-Replikation.

HinweisHinweis

Stellen Sie, um inkonsistente Daten zu vermeiden, in einer Peer-to-Peer-Topologie sicher, dass keine Konflikte auftreten, auch wenn die Konflikterkennung aktiviert ist. Damit sichergestellt ist, dass Schreibvorgänge für eine bestimmte Zeile nur an einem Knoten durchgeführt werden, müssen Anwendungen, die auf Daten zugreifen und diese ändern, Einfügungen, Aktualisierungen und Löschungen partitionieren. Diese Partitionierung gewährleistet, dass Änderungen an einer bestimmten Zeile, die von einem Knoten stammen, mit allen anderen Knoten in der Topologie synchronisiert werden, bevor die Zeile von einem anderen Knoten geändert wird. Wenn eine Anwendung ausgereifte Fähigkeiten zur Konflikterkennung und -lösung erfordert, verwenden Sie die Mergereplikation. Weitere Informationen finden Sie unter Mergereplikation (Übersicht) und Erkennen und Beseitigen von Konflikten bei der Mergereplikation.

Peer-to-Peer-Topologien

In folgenden Szenarien werden die typischen Verwendungsarten der Peer-to-Peer-Replikation erläutert.

Topologie mit zwei teilnehmenden Datenbanken

Peer-to-Peer-Replikation, zwei Knoten

Die beiden oben stehenden Abbildungen zeigen jeweils zwei teilnehmende Datenbanken, bei denen der Benutzerverkehr über einen Anwendungsserver an die Datenbanken geleitet wird. Diese Konfiguration kann für eine Vielzahl von Anwendungen, von Websites bis zu Arbeitsgruppenanwendungen, verwendet werden, und bietet folgende Vorteile:

  • Verbesserte Leseleistung, da Lesevorgänge über zwei Server verteilt werden.

  • Höhere Verfügbarkeit bei Wartungserfordernissen oder bei Ausfällen an einem Knoten.

In beiden Abbildungen wird für die Leseaktivität ein Lastenausgleich zwischen den teilnehmenden Datenbanken ausgeführt, die Updates werden jedoch anders verarbeitet.

  • Links werden Aktualisierungen zwischen den zwei Servern partitioniert. Falls die Datenbank einen Produktkatalog enthält, können Sie beispielsweise veranlassen, dass eine benutzerdefinierte Anwendung Aktualisierungen für Produktnamen, die mit den Buchstaben A bis M beginnen, an Knoten A und Aktualisierungen für Produktnamen, die mit den Buchstaben N bis Z beginnen, an Knoten B leitet. Aktualisierungen werden dann auf dem jeweils anderen Knoten repliziert.

  • Auf der rechten Seite werden alle Aktualisierungen an Knoten B geleitet. Von dort aus werden Aktualisierungen auf Knoten A repliziert. Wenn B offline ist (z. B. aus Wartungsgründen), kann der Anwendungsserver sämtliche Aktivitäten an B leiten. Ist B wieder online, können Aktualisierungen auf ihn geleitet werden, und der Anwendungsserver kann alle Aktualisierungen zurück an B oder weiterhin an A leiten.

Die Peer-to-Peer-Replikation unterstützt beide Vorgehensweisen, aber das Beispiel für die zentrale Aktualisierung auf der rechten Seite wird oft auch bei der standardmäßigen Transaktionsreplikation verwendet.

Topologien mit drei oder mehr teilnehmenden Datenbanken

Peer-to-Peer-Replikation an verteilte Standorte

Die oben stehende Abbildung zeigt drei teilnehmende Datenbanken, die Daten für einen weltweiten Software-Support-Anbieter mit Niederlassungen in Los Angeles, London und Taipeh bereitstellen.Die Supportmitarbeiter in den jeweiligen Niederlassungen nehmen Kundenanrufe entgegen und geben Informationen zu sämtlichen Kundenanrufen ein und aktualisieren diese. Der Zeitunterschied zwischen den Zeitzonen, in denen sich die drei Niederlassungen befinden, beträgt jeweils acht Stunden, sodass sich die Arbeitszeiten nicht überschneiden. Wenn die Niederlassung in Taipeh schließt, beginnt der Arbeitstag in der Londoner Niederlassung.Wenn ein Anruf noch bearbeitet wird, wenn eine Niederlassung schließt, wird der Anruf an einen Mitarbeiter in der Niederlassung übertragen, die als nächste öffnet.

Jeder Standort verfügt über eine Datenbank und einen Anwendungsserver, mit deren Hilfe die Supportmitarbeiter Informationen zu den Kundenanrufen eingeben und aktualisieren können. Die Topologie wird anhand der Uhrzeit partitioniert. Aktualisierungen finden nur auf dem Knoten statt, der zum gegebenen Zeitpunkt für die Geschäftstätigkeit geöffnet ist. Die Aktualisierungen werden dann an die anderen teilnehmenden Datenbanken geleitet.Diese Topologie bietet folgende Vorteile:

  • Unabhängigkeit ohne Isolation: Jede Niederlassung kann Daten unabhängig von den anderen Niederlassungen einfügen, aktualisieren oder löschen. Jedoch können alle Niederlassungen die Daten nutzen, da sie auf allen anderen teilnehmenden Datenbanken repliziert werden.

  • Höhere Verfügbarkeit bei Ausfällen oder Wartungserfordernissen an einer oder mehreren der teilnehmenden Datenbanken.

    Peer-to-Peer-Replikation, drei und vier Knoten

Die oben stehende Abbildung zeigt, wie der drei Knoten umfassenden Topologie ein Knoten hinzugefügt wird. Ein Knoten könnte in diesem Szenario aus folgenden Gründen hinzugefügt werden:

  • Da eine andere Niederlassung geöffnet ist.

  • Um eine höhere Verfügbarkeit für Wartungszwecke oder eine höhere Fehlertoleranz beim Ausfall eines Datenträgers oder anderer schwerwiegender Fehler zu bieten.

Beachten Sie, dass sowohl in der drei Knoten umfassenden als auch in der vier Knoten umfassenden Topologie sämtliche Datenbanken an alle anderen Datenbanken veröffentlichen und von diesen abonnieren. Dadurch wird eine maximale Verfügbarkeit im Fall von Wartungserfordernissen oder beim Ausfall eines oder mehrerer Knoten erreicht.Da Knoten hinzugefügt werden, müssen Sie die Verfügbarkeits- und Skalierbarkeitserfordernisse gegenüber der Leistung und der Komplexität der Bereitstellung und der Verwaltung abgleichen.

Konfigurieren der Peer-to-Peer-Replikation

Die Konfiguration der Peer-to-Peer-Replikationstopologie ist der Konfiguration einer Reihe von standardmäßigen Transaktionsveröffentlichungen und -abonnements sehr ähnlich. Die im folgenden Thema beschriebenen Schritte stellen die Konfiguration eines drei Knoten umfassenden Systems dar, das der auf der linken Seite in der oben stehenden Abbildung dargestellten Peer-to-Peer-Topologie ähnelt.

So konfigurieren Sie die Peer-to-Peer-Transaktionsreplikation

Überlegungen für die Verwendung der Peer-to-Peer-Replikation

Dieser Abschnitt enthält Informationen und Richtlinien, die Sie beachten sollten, wenn Sie Peer-to-Peer-Replikation verwenden.

Allgemeine Überlegungen

  • Die Peer-to-Peer-Replikation ist nur in SQL Server 2008 Enterprise verfügbar.

  • Alle an der Peer-to-Peer-Replikation teilnehmenden Datenbanken sollten identische Schemas und Daten enthalten:

    • Objektnamen, das Objektschema und Veröffentlichungsnamen sollten identisch sein.

    • Bei Veröffentlichungen müssen Schemaänderungen repliziert werden dürfen. (Dies entspricht der Einstellung 1 für die Veröffentlichungseigenschaft replicate_ddl, also der Standardeinstellung.) Weitere Informationen finden Sie unter Vornehmen von Schemaänderungen in Veröffentlichungsdatenbanken.

    • Zeilen- und Spaltenfilterung werden nicht unterstützt.

  • Es wird empfohlen, dass jeder Knoten seine eigene Verteilungsdatenbank verwendet.Hierdurch wird das Ausfallsrisiko auf mehrere Knoten verteilt.

  • Tabellen und andere Objekte können nicht in mehreren Peer-to-Peer-Veröffentlichungen innerhalb einer Veröffentlichungsdatenbank eingeschlossen sein.

  • Eine Veröffentlichung muss für die Peer-to-Peer-Replikation aktiviert werden, bevor Abonnements erstellt werden können.

  • Abonnements müssen mithilfe einer Sicherung oder mit der Option 'replication support only' initialisiert werden.Weitere Informationen finden Sie unter Initialisieren eines Transaktionsabonnements ohne Snapshot.

  • Die Verwendung von Identitätsspalten wird nicht empfohlen.Bei der Verwendung von Identitäten müssen Sie die den Tabellen zugewiesenen Bereiche in jeder teilnehmenden Datenbank manuell verwalten. Weitere Informationen finden Sie im Abschnitt zum Zuweisen von Bereichen bei der manuellen Verwaltung von Identitätsbereichen im Thema Replizieren von Identitätsspalten.

Featurebezogene Einschränkungen

Peer-to-Peer-Replikation unterstützt die zentralen Features der Transaktionsreplikation, unterstützt jedoch nicht die folgenden Optionen:

  • Initialisierung und erneute Initialisierung mit einem Snapshot.

  • Zeilen- und Spaltenfilter.

  • Timestamp-Spalten.

  • Nicht-SQL Server-Verleger und -Abonnenten.

  • Abonnements für sofortige Aktualisierung und verzögerte Aktualisierung über eine Warteschlange.

  • Anonyme Abonnements.

  • Teilabonnements

  • Anfügbare Abonnements und transformierbare Abonnements. (Beide Optionen wurden mit SQL Server 2005 als veraltet markiert.)

  • Freigegebene Verteilungs-Agents.

  • Der Verteilungs-Agent-Parameter -SubscriptionStreams und der Protokolllese-Agent-Parameter -MaxCmdsInTran.

  • Die Artikeleigenschaften @destination_owner und @destination_table.

Für folgende Eigenschaften gelten spezielle Bedingungen:

  • Für die Veröffentlichungseigenschaft @allow_initialize_from_backup ist der Wert true erforderlich.

  • Für die Artikeleigenschaft @replicate_ddl ist der Wert true erforderlich; für @identityrangemanagementoption ist der Wert manual erforderlich; und für @status muss der Wert auf 24 festgelegt werden.

  • Der Wert für die Artikeleigenschaften @ins_cmd, @del_cmd und @upd_cmd darf nicht auf SQL festgelegt werden.

  • Für die Abonnementeigenschaft @sync_type ist der Wert none oder automatic erforderlich.

Überlegungen in Bezug auf die Wartung

Die folgenden Aktionen erfordern, dass das System in den inaktiven Status versetzt werden muss. Dazu müssen alle Aktivitäten an veröffentlichten Tabellen in allen Knoten beendet werden, und es muss sichergestellt werden, dass jeder Knoten alle Änderungen von allen anderen Knoten erhalten hat.

  • Hinzufügen eines SQL Server 2005-Knotens zu einer vorhandenen Topologie

  • Hinzufügen eines Artikels zu einer vorhandenen Veröffentlichung

  • Vornehmen von Schemaänderungen

  • Wiederherstellen eines Knotens von einer Sicherung