Peer-to-Peer-Transaktionsreplikation

Aktualisiert: 12. Dezember 2006

Die Peer-to-Peer-Transaktionsreplikation ist auf Anwendungen ausgerichtet, die möglicherweise Daten in einer der an einer Replikation beteiligten Datenbanken lesen oder ändern. Eine Online-Shopping-Anwendung eignet sich beispielsweise gut für die Peer-to-Peer-Replikation: Die Anwendungsleistung kann verbessert werden, indem Abfragen, die Daten lesen, über mehrere Datenbanken verteilt werden. Zudem kann eine Anwendung, sofern Hostingserver der Datenbanken nicht verfügbar sind, so programmiert werden, dass der Verkehr an die verbleibenden Server geroutet wird, die identische Kopien der Daten enthalten. Die Leseleistung wird verbessert, da die Aktivität auf alle Knoten verteilt werden kann. Die gesamte Leistung für Aktualisierungen, Einfügungen und Löschungen in der Topologie ähnelt der eines einzelnen Knotens, da letztendlich alle Änderungen an alle Knoten weitergegeben werden.

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 ausgeführt werden. Die Replikation erkennt, wenn eine Änderung auf einen bestimmten Knoten angewendet wurde. So wird verhindert, dass Änderungen die Knoten mehrmals durchlaufen.

Hinweis:

Benutzerdefinierte Anwendungen, die auf Daten zugreifen und diese ändern, müssen sicherstellen, dass Einfügungen, Aktualisierungen und Löschungen partitioniert werden. Auf diese Weise wird sichergestellt, dass Änderungen an einer bestimmten Zeile, die von einem Knoten stammen, mit allen anderen Datenbanken in der Topologie synchronisiert werden, bevor die Zeile von einem anderen Knoten geändert wird. Falls eine Anwendung gleichzeitig miteinander in Konflikt stehende Änderungen an einer bestimmten Zeile auf mehreren Knoten ausführt, verwenden Sie die Mergereplikation, die sich gut zur Lösung von Konflikten eignet. Weitere Informationen zur Mergereplikation finden Sie unter Mergereplikation (Übersicht).

Die standardmäßige Transaktionsreplikation geht von schreibgeschützten Abonnenten aus und ist hierarchisch strukturiert. Normalerweise veröffentlicht ein einzelner Verleger Daten für einen oder mehrere Abonnenten. Die standardmäßige Transaktionsreplikation unterstützt außerdem eine Wiederveröffentlichungshierarchie: Aktualisierungen werden von einem Verleger einer Reihe von Wiederveröffentlichungsabonnenten übermittelt, die wiederum einer Reihe finaler Endknotenabonnenten Aktualisierungen übermitteln. Aktualisierbare Abonnements ermöglichen es Abonnenten, Änderungen per Push zurück an den Verleger zu geben. Die Anordnung ist aber nach wie vor hierarchisch, da die Änderungen der hierarchischen Struktur folgen, wenn sie zwischen Abonnenten und Verlegern verschoben werden. Im Gegensatz zur schreibgeschützten Transaktionsreplikation und zur Transaktionsreplikation mit aktualisierbaren Abonnements handelt es sich bei den Beziehungen zwischen Knoten in einer Peer-to-Peer-Replikationstopologie um Peer-Beziehungen und nicht um hierarchische Beziehungen, und jeder Knoten enthält identische Schemas und Daten.

Hinweis:

Obwohl Aktualisierungen an mehreren teilnehmenden Datenbanken vorgenommen werden können, ist es wichtig zu wissen, dass Peer-to-Peer-Topologien die Publikationsoptionen für sofortige Aktualisierung oder verzögerte Aktualisierung über eine Warteschlange nicht benötigen oder zulassen. Weitere Informationen zur sofortigen Aktualisierung oder verzögerten Aktualisierung über eine Warteschlange finden Sie unter Aktualisierbare Abonnements für die Transaktionsreplikation.

Peer-to-Peer-Topologien

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

Topologie mit zwei teilnehmenden Datenbanken

Die 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 hin 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.

• Auf der linken Seite werden Aktualisierungen zwischen den beiden 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–M beginnen, an Knoten "A" und Aktualisierungen für Produktnamen, die mit den Buchstaben N–Z beginnen, an Knoten "B" leitet. Aktualisierungen werden dann auf den 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 "A" 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

Die oben stehende Abbildung zeigt drei teilnehmende Datenbanken, die das Back-End für einen weltweiten Software-Support-Anbieter mit Niederlassungen in Los Angeles, London und Taipei darstellen. 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 8 Stunden, sodass sich die Arbeitszeiten nicht überschneiden. Wenn die Niederlassung in Taipei 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 ist anhand der Uhrzeit partitioniert, sodass Aktualisierungen nur auf dem Knoten stattfinden, 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. Alle Niederlassungen können Daten unabhängig voneinander einfügen, aktualisieren oder löschen, die Daten aber als Freigabe nutzen, da sie auf alle anderen teilnehmenden Datenbanken repliziert werden.
• Höhere Verfügbarkeit bei Ausfällen oder Wartungserfordernissen an einer der teilnehmenden Datenbanken.
  

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

• Da eine andere Niederlassung geöffnet ist.
• Um eine höhere Verfügbarkeit für Wartungszwecke oder zur Erhöhung der Fehlertoleranz bei schwerwiegenden Fehlern 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. Hierdurch wird eine maximale Verfügbarkeit im Fall von Wartungserfordernissen oder beim Ausfall von einem oder mehreren Knoten ermöglicht. 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 Transaktionspublikationen und -abonnements sehr ähnlich. Die im folgenden Thema beschriebenen Schritte stellen die Konfiguration eines drei Knoten umfassenden Systems dar, die der im oben stehenden Diagramm auf der linken Seite dargestellten Konfiguration ähnelt.

So konfigurieren Sie die Peer-to-Peer-Transaktionsreplikation

• SQL Server Management Studio: Vorgehensweise: Konfigurieren der Peer-to-Peer-Transaktionsreplikation (SQL Server Management Studio)
• Replikationsprogrammierung mit Transact-SQL: How to: Configure Peer-to-Peer Transactional Replication (Replication Transact-SQL Programming)

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

Berücksichtigen Sie bei der Verwendung der Peer-to-Peer-Replikation folgende Aspekte:

Allgemeine Überlegungen

• Die Peer-to-Peer-Replikation ist nur in SQL Server 2005 Enterprise Edition verfügbar.
• Alle teilnehmenden Datenbanken sollten identische Schemas und Daten enthalten.
  • Objektnamen, das Objektschema und Publikationsnamen sollten in den teilnehmenden Datenbanken identisch sein.
  • Bei Publikationen müssen Schemaänderungen repliziert werden dürfen (Einstellung 1 für die Publikationseigenschaft replicate_dll, bei der es sich um die Standardeinstellung handelt). Weitere Informationen finden Sie unter Vornehmen von Schemaänderungen in Publikationsdatenbanken.
  • Zeilen- und Spaltenfilterung werden nicht unterstützt.
• Es empfiehlt sich, 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-Publikationen innerhalb einer Publikationsdatenbank eingeschlossen sein.
• Eine Publikation 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 'Nur Replikationsunterstützung' initialisiert werden. Weitere Informationen finden Sie unter Initialisieren eines Transaktionsabonnements ohne Snapshot.
• Die Konflikterkennung und -lösung wird nicht angeboten. Aktualisierungen für eine bestimmte Zeile sollten nur in einer Datenbank vorgenommen werden, bis diese mit ihren Peers synchronisiert wurde. Die Anwendung kann diesen Vorgang beispielsweise ausführen, indem sie Aktualisierungen für mehrere Zeilen an einen bestimmten Knoten leitet.
• 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

Die Peer-to-Peer-Replikation unterstützt die zentralen Features der Transaktionsreplikation. Folgende Optionen werden nicht unterstützt:

• 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 (beides in SQL Server 2005 als veraltet markiert).
• Gemeinsam verwendete 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 Publikationseigenschaft @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

• Für die folgenden Aktionen muss das System in den Ruhezustand (Quiesce) versetzt werden (Beenden der Aktivität für veröffentlichte Tabellen an allen Knoten und Sicherstellung, dass jeder Knoten alle Änderungen von allen anderen Knoten empfangen hat).
  • Hinzufügen eines Knotens zu einer vorhandenen Topologie
  • Hinzufügen eines Artikels zu einer vorhandenen Publikation
  • Vornehmen von Schemaänderungen
  • Wiederherstellen eines Knotens von einer Sicherung
    Weitere Informationen finden Sie unter Vorgehensweise: Konfigurieren der Peer-to-Peer-Transaktionsreplikation (SQL Server Management Studio), How to: Quiesce a Replication Topology (Replication Transact-SQL Programming) und How to: Administer a Peer-to-Peer Topology (Replication Transact-SQL Programming).
• Wenn Sie einer Peer-to-Peer-Topologie einen neuen Knoten hinzufügen, sollten Sie nur von Sicherungen wiederherstellen, die erstellt wurden, nachdem der neue Knoten hinzugefügt wurde. Weitere Informationen finden Sie unter Vorgehensweise: Konfigurieren der Peer-to-Peer-Transaktionsreplikation (SQL Server Management Studio).
• Sie können keine Abonnements in einer Peer-to-Peer-Topologie erneut initialisieren. Wenn Sie sicherstellen müssen, dass ein Knoten eine neue Kopie der Daten aufweist, stellen Sie eine Sicherung auf dem Knoten wieder her.

Änderungsverlauf

Siehe auch

Konzepte

Strategien zum Sichern und Wiederherstellen einer Snapshot- und Transaktionsreplikation
Publikationstypen der Transaktionsreplikation

Andere Ressourcen

How to: Administer a Peer-to-Peer Topology (Replication Transact-SQL Programming)

Hilfe und Informationen

Informationsquellen für SQL Server 2005