Peer-zu-Peer-Transaktionsreplikation

Gilt für:SQL Server

Peer-zu-Peer-Replikation bietet eine skalierbare Lösung mit hoher Verfügbarkeit, da Kopien der Daten auf mehreren Serverinstanzen verwaltet werden, die auch als Knotenbezeichnet werden. Auf der Grundlage der Transaktionsreplikation aufbauend, gibt die Peer-zu-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-zu-Peer-Replikation Datenredundanz, die die Verfügbarkeit der Daten erhöht.

Betrachten Sie eine Webanwendung. Sie kann von Peer-zu-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-zu-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, Updates 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 das Update kann sogar verloren gehen, wenn die Zeile an andere Knoten übermittelt 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-zu-Peer-Replikation schließt die Option ein, die Konflikterkennung für eine gesamte Peer-zu-Peer-Topologie zu aktivieren. Diese Option hilft, den Problemen vorzubeugen, die sich aus nicht erkannten Konflikten, einschließlich inkonsistentem Verhalten von Anwendungen und verlorenen Updates 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 Conflict Detection in Peer-to-Peer Replication.

Hinweis

Stellen Sie, um inkonsistente Daten zu vermeiden, in einer Peer-zu-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, Updates 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 und Erkennen und Beseitigen von Konflikten bei der Mergereplikation.

Peer-zu-Peer-Topologien

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

Topologie mit zwei teilnehmenden Datenbanken

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 Reihe von Anwendungen verwendet werden, von Websites bis hin zu Arbeitsgruppenanwendungen und bietet die folgenden Vorteile:

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

• Höhere Verfügbarkeit, wenn Standard Intensität erforderlich ist oder ein Fehler bei einem Knoten auftritt.

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

• Auf der rechten Seite werden alle Updates an Knoten B weitergeleitet. Von dort aus werden Updates in Knoten A repliziert. Wenn B offline ist (z. B. für Standard Tenance), kann der Anwendungsserver alle Aktivitäten an A weiterleiten. Wenn B wieder online ist, können Updates dorthin fließen, und der Anwendungsserver kann alle Updates zurück nach B verschieben oder sie weiterhin an A weiterleiten.

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

Topologien mit drei oder mehr teilnehmenden Datenbanken

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. Die Zeitzonen für die drei Büros sind acht Stunden auseinander, daher gibt es keine Überschneidungen am Arbeitstag. 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. Updates finden nur auf dem Knoten statt, der zum gegebenen Zeitpunkt für die Geschäftstätigkeit geöffnet ist. Die Updates werden dann an die anderen teilnehmenden Datenbanken geleitet. Diese Topologie bietet folgende Vorteile:

• Unabhängigkeit ohne Isolierung: Jedes Büro kann Daten unabhängig einfügen, aktualisieren oder löschen, aber auch die Daten freigeben, da sie in alle anderen teilnehmenden Datenbanken repliziert wird.

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

  

  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 bereitzustellen, um Standard Tenance zu unterstützen oder die Fehlertoleranz zu erhöhen, wenn ein Datenträgerfehler oder ein anderer größerer Fehler auftritt.

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. Dies bietet maximale Verfügbarkeit, wenn Standard Anforderungen oder Fehler eines oder mehrerer Knoten vorhanden sind. 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-zu-Peer-Replikation

Das Konfigurieren einer Peer-to-Peer-Replikationstopologie ähnelt dem Konfigurieren einer Reihe von standardtransaktionellen Publikationen und Abonnements. Die in den folgenden Artikeln beschriebenen Schritte zeigen die Konfiguration eines Drei-Knoten-Systems, ähnlich der konfiguration auf der linken Seite in der vorherigen Abbildung, die Peer-to-Peer-Topologie zeigt.

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

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

Allgemeine Überlegungen

• Peer-to-Peer-Replikation ist nur in der Enterprise-Edition von SQL Server verfügbar.

• Alle an der Peer-zu-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 ist eine Einstellung von 1 für die Publikationseigenschaft replicate_ddl, die die Standardeinstellung ist.) Weitere Informationen finden Sie unter "Vornehmen von Schemaänderungen in Publikationsdatenbanken".

  • Zeilen- und Spaltenfilter werden nicht unterstützt.

• Jeder Knoten sollte eine eigene Verteilungsdatenbank verwenden. Hierdurch wird das Ausfallsrisiko auf mehrere Knoten verteilt.

• Tabellen und andere Objekte können nicht in mehrere Peer-to-Peer-Publikationen in einer einzelnen Publikationsdatenbank eingeschlossen werden.

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

• Abonnements müssen mithilfe einer Sicherung oder mit der replication support only Option initialisiert werden. Weitere Informationen finden Sie unter Initialize a Transactional Subscription Without a Snapshotinitialisiert wird.

• Verwenden Sie keine Identitätsspalten. Bei der Verwendung von Identitäten müssen Sie die den Tabellen zugewiesenen Bereiche in jeder teilnehmenden Datenbank manuell verwalten. Weitere Informationen finden Sie unter Zuweisen von Bereichen für die manuelle Identitätsbereichsverwaltung.

Featureeinschränkungen

Die Peer-to-Peer-Replikation unterstützt die Kernfunktionen der Transaktionsreplikation, unterstützt aber nicht die folgenden Optionen:

• Initialisierung und erneute Initialisierung mit einer Momentaufnahme.

• Zeilen- und Spaltenfilter.

• Timestamp-Spalten.

• Nicht-SQL Server-Herausgeber und -Abonnenten.

• Abonnements mit sofortigem Update und mit verzögertem Update über eine Warteschlange.

• Anonyme Abonnements.

• Teilabonnements

• Anfügbare Abonnements und transformierbare Abonnements. (Beide Optionen sind in SQL Server 2005 (9.x) veraltet.)

• Freigegebene Verteilungs-Agents.

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

• Die Artikeleigenschaften @destination_owner und @destination_table.

• Peer-to-Peer-Transaktionsreplikation unterstützt das Erstellen eines unidirektionalen Transaktionsabonnements für eine Peer-to-Peer-Publikation nicht.

• Die Peer-to-Peer-Transaktionsreplikation unterstützt keine Veröffentlichungstabellen mit berechneten Spalten als Teil ihres Primärschlüssels.

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 die Option 24 festgelegt sein.

• Der Wert für Artikeleigenschaften @ins_cmd, @del_cmdund @upd_cmd kann nicht auf SQL festgelegt werden.

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

• SQL Server 2019 (15.x) CU 13 führt die Publikationseigenschaft ein. @p2p_confictdetection_policy Der Standardparameterwert ist originatorid. Dieser Wert löst den Konflikt auf Grundlage der Ursprungs-ID auf. Der Parameterwert lastwriter löst den Konflikt anhand des letzten Writers auf.

Überlegungen in Bezug auf die Wartung

Für einige Aktionen muss das System in den inaktiven Status versetzt werden. 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.

Aktion	Nur SQL Server 2005-Peers oder eine Kombination aus SQL Server 2005- und SQL Server 2008-Peers und höher	Nur SQL Server 2005-Peers oder eine Kombination aus SQL Server 2005- und SQL Server 2008-Peers und höher	SQL Server 2008-Peers und höher	SQL Server 2008-Peers und höher
Hinzufügen eines Knotens zur Topologie	2 Knoten in vollständiger Topologie: Kein Versetzen in inaktiven Status erforderlich. Verwenden Sie sync_type = 'initialize with backup'.	Mehr als 2 Knoten: Versetzen in inaktiven Status erforderlich.	sync_type = 'replication support only': Versetzen in inaktiven Status erforderlich.	sync_type = 'initialize with backup' und 'initialize from lsn': Kein Versetzen in inaktiven Status erforderlich.

Für Änderungen am Topologieschema (Hinzufügen oder Löschen von Artikeln) ist ein Versetzen in den inaktiven Status erforderlich. Weitere Informationen finden Sie unter Verwalten einer Peer-to-Peer-Topologie (Replikation Transact-SQL-Programmierung).

Zum Entfernen eines Knotens aus der Topologie ist kein Versetzen in den inaktiven Status erforderlich.

Zum Ändern der Artikeleigenschaften mit sp_changearticle ist kein Versetzen in den inaktiven Status erforderlich. Die folgenden Eigenschaften dürfen geändert werden (für P2P): description, ins_cmd, upd_cmdund del_cmd .

Für Änderungen am Artikelschema (Hinzufügen oder Löschen von Spalten) ist kein Versetzen in den inaktiven Status erforderlich.

• Artikel hinzufügen: Zum Hinzufügen eines Artikels zu einer vorhandenen Konfiguration muss das System in den inaktiven Status versetzt werden. Danach wird die CREATE TABLE-Anweisung ausgeführt, die Ausgangsdaten werden auf jeden Knoten der Topologie geladen und der neue Artikel wird jedem Knoten der Topologie hinzugefügt.

• Artikel löschen: Zur Aufrechterhaltung eines konsistenten Status auf allen Knoten muss die Topologie in den inaktiven Status versetzt werden.

Weitere Informationen finden Sie unter "Stilllegen einer Replikationstopologie (Replikation Transact-SQL-Programmierung) und Verwalten einer Peer-to-Peer-Topologie (Replikation Transact-SQL-Programmierung)".

• Wenn Sie einer Peer-zu-Peer-Topologie einen neuen Knoten hinzufügen, sollte nur aus Sicherungen wiederhergestellt werden, die vor dem Hinzufügen des neuen Knoten erstellt wurden.

• Sie können Abonnements in einer Peer-to-Peer-Topologie nicht erneut initialisieren. Wenn Sie sicherstellen müssen, dass ein Knoten eine neue Kopie der Daten besitzt, stellen Sie an diesem Knoten eine Sicherung wieder her.

Weitere Informationen

Verwalten einer Peer-zu-Peer-Topologie (Replikationsprogrammierung mit Transact-SQL)
Strategien zum Sichern und Wiederherstellen einer Momentaufnahme- und Transaktionsreplikation
Transaktionsreplikation