Peer-to-Peer-Transaktionsreplikation

Die Peer-to-Peer-Replikation bietet eine Skalierungs- und Hochverfügbarkeitslösung, indem Kopien von Daten über mehrere Serverinstanzen hinweg verwaltet werden, auch als Knoten bezeichnet. Basierend auf der Transaktionsreplikation verteilt die Peer-to-Peer-Replikation transaktionskonsensierte Änderungen in nahezu Echtzeit. Auf diese Weise können Anwendungen, die eine Skalierung von Lesevorgängen erfordern, die Lesevorgänge von Clients über mehrere Knoten verteilen. Da Daten in nahezu Echtzeit über die Knoten hinweg verwaltet werden, bietet die Peer-to-Peer-Replikation Datenredundanz, wodurch die Verfügbarkeit von Daten erhöht wird.

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

• Katalogabfragen und andere Lesevorgänge werden über mehrere Knoten verteilt. Dadurch kann die Leistung konsistent bleiben, während die Anzahl der Lesevorgänge zunimmt.

• Wenn einer der Knoten im System fehlschlägt, kann eine Anwendungsschicht die Schreibvorgänge für diesen Knoten an einen anderen Knoten umleiten. Dadurch bleibt die Verfügbarkeit erhalten.

• Wenn ein Knoten Eine Wartung erfordert oder das gesamte System ein Upgrade erfordert, kann jeder Knoten offline geschaltet und wieder zum System hinzugefügt werden, ohne die Verfügbarkeit der Anwendung zu beeinträchtigen.

Obwohl die Peer-to-Peer-Replikation das Skalieren von Lesevorgängen ermöglicht, ist die Schreibleistung für die Topologie ähnlich wie bei einem einzelnen Knoten. Dies liegt daran, dass letztendlich alle Einfügungen, Aktualisierungen und Löschungen an alle Knoten verteilt werden. Die Replikation erkennt, wann eine Änderung auf einen bestimmten Knoten angewendet wurde und verhindert, dass Änderungen mehrmals durch die Knoten durchlaufen werden. Es wird dringend empfohlen, dass Schreibvorgänge für jede Zeile nur bei einem Knoten ausgeführt werden, und zwar aus den folgenden Gründen:

• Wenn eine Zeile an mehreren Knoten geändert wird, kann dies zu einem Konflikt oder sogar zu einer verlorenen Aktualisierung führen, wenn die Zeile an andere Knoten weitergegeben wird.

• Es gibt immer einige Wartezeiten, wenn Änderungen repliziert werden. Für Anwendungen, für die die neueste Änderung sofort sichtbar sein muss, kann ein dynamischer Lastenausgleich für die Anwendung über mehrere Knoten hinweg problematisch sein.

Die Peer-to-Peer-Replikation enthält die Option, die Konflikterkennung über eine Peer-zu-Peer-Topologie hinweg zu aktivieren. Mit dieser Option können Sie die Probleme verhindern, die aufgrund nicht erkannter Konflikte verursacht werden, einschließlich inkonsistenter Anwendungsverhalten und verlorener Updates. Durch aktivieren dieser Option wird standardmäßig eine widersprüchliche Änderung als kritischer Fehler behandelt, der den Fehler des Verteilungs-Agents verursacht. Im Falle eines Konflikts verbleibt die Topologie in einem inkonsistenten Zustand, bis der Konflikt manuell aufgelöst wird und die Daten in der gesamten Topologie konsistent sind. Weitere Informationen finden Sie unter Konflikterkennung in Peer-to-Peer-Replikation.

Peer-to-Peer-Topologien

Die folgenden Szenarien veranschaulichen typische Verwendungsmöglichkeiten für die Peer-to-Peer-Replikation.

Topologie mit zwei teilnehmenden Datenbanken

Beide abbildungen zeigen zwei teilnehmende Datenbanken, wobei der Benutzerdatenverkehr über einen Anwendungsserver an die Datenbanken weitergeleitet wird. Diese Konfiguration kann für eine Vielzahl von Anwendungen verwendet werden, von Websites bis hin zu Arbeitsgruppenanwendungen und bietet die folgenden Vorteile:

• Verbesserte Leseleistung, da Lesevorgänge auf zwei Servern verteilt sind.

• Höhere Verfügbarkeit bei erforderlicher Wartung oder im Falle eines Ausfalls an einem Knoten.

In beiden Abbildungen wird die Leseaktivität zwischen den teilnehmenden Datenbanken lastenausgeglichen, Aktualisierungen werden jedoch unterschiedlich behandelt.

• Auf der linken Seite werden Updates zwischen den beiden Servern partitioniert. Wenn die Datenbank einen Produktkatalog enthielt, könnten Sie z. B. über eine benutzerdefinierte Anwendung direkte Updates für Knoten A für Produktnamen verfügen, die mit A bis M beginnen, und direkte Updates für Knoten B für Produktnamen, die mit N bis Z beginnen. Updates werden dann auf den 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. zur Wartung), 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.

Peer-to-Peer-Replikation kann beide Ansätze unterstützen, aber das zentrale Updatebeispiel auf der rechten Seite wird häufig auch mit der standardmäßigen Transaktionsreplikation verwendet.

Topologien mit drei oder mehr teilnehmenden Datenbanken

Die vorangehende Abbildung zeigt drei teilnehmende Datenbanken, die Daten für eine weltweite Softwaresupportorganisation mit Büros in Los Angeles, London und Taipeh bereitstellen. Die Supporttechniker in jedem Büro nehmen Kundenanrufe an und geben Informationen zu jedem Kundenanruf ein und aktualisieren sie. Die Zeitzonen für die drei Büros sind acht Stunden auseinander, daher gibt es keine Überschneidungen am Arbeitstag. Als das Büro in Taipeh schließt, öffnet das Büro in London für den Tag. Wenn ein Anruf noch in Bearbeitung ist, während ein Büro geschlossen wird, wird der Anruf an einen Vertreter am nächsten Büro weitergeleitet, um es zu öffnen.

Jeder Standort verfügt über eine Datenbank und einen Anwendungsserver, der von den Supporttechnikern verwendet wird, während sie Informationen zu Kundenanrufen eingeben und aktualisieren. Die Topologie wird nach Zeit partitioniert. Daher treten Updates nur auf dem Knoten auf, der derzeit für Unternehmen geöffnet ist, und dann fließen die Aktualisierungen zu den anderen teilnehmenden Datenbanken. Diese Topologie bietet die folgenden 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 im Falle eines Ausfalls oder zur Wartung bei einer oder mehreren der teilnehmenden Datenbanken.

  

Die vorherige Abbildung zeigt das Hinzufügen eines Knotens zur Topologie mit drei Knoten. In diesem Szenario könnte aus folgenden Gründen ein Knoten hinzugefügt werden:

• Da ein anderes Büro geöffnet wird.

• Um eine höhere Verfügbarkeit bereitzustellen, um Wartung zu unterstützen oder fehlertoleranz zu erhöhen, wenn ein Datenträgerfehler oder ein anderer größerer Fehler auftritt.

Beachten Sie, dass in den Topologien mit drei und vier Knoten alle Datenbanken veröffentlicht und alle anderen Datenbanken abonniert werden. Dies bietet maximale Verfügbarkeit im Falle von Wartungsanforderungen oder Fehlern eines oder mehrerer Knoten. Da Knoten hinzugefügt werden, müssen Sie die Verfügbarkeits- und Skalierbarkeitsanforderungen mit der Leistung und der Komplexität der Bereitstellung und Verwaltung in Einklang bringen.

Konfiguration der Peer-to-Peer-Replikation

Das Konfigurieren einer Peer-to-Peer-Replikationstopologie ähnelt dem Konfigurieren einer Reihe von standardmäßigen Transaktionspublikationen und Abonnements. Die in den folgenden Themen beschriebenen Schritte zeigen die Konfiguration eines Drei-Knoten-Systems, ähnlich wie die auf der linken Seite in der vorherigen Abbildung dargestellte Konfiguration, die Peer-to-Peer-Topologie zeigt.

Überlegungen zur Verwendung der Peer-to-Peer-Replikation

Dieser Abschnitt enthält Informationen und Richtlinien, die Sie bei der Verwendung der Peer-to-Peer-Replikation berücksichtigen sollten.

Allgemeine Überlegungen

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

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

  • Objektnamen, Objektschema und Publikationsnamen sollten identisch sein.

  • Publikationen müssen das Replizieren von Schemaänderungen zulassen. (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.

• Es wird empfohlen, dass jeder Knoten eine eigene Verteilungsdatenbank verwendet. Dadurch wird das Potenzial beseitigt, einen einzigen Fehlerpunkt zu haben.

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

• Eine Publikation muss für die Peer-zu-Peer-Replikation aktiviert sein, bevor Abonnements erstellt werden.

• Abonnements müssen mithilfe einer Sicherung oder mit der Option "Nur Replikationsunterstützung" initialisiert werden. Weitere Informationen finden Sie unter Initialisieren eines Transaktionsabonnements ohne Schnappschuss.

• Die Verwendung von Identitätsspalten wird nicht empfohlen. Wenn Sie Identitäten verwenden, müssen Sie die Bereiche, die den Tabellen in jeder teilnehmenden Datenbank zugewiesen sind, manuell verwalten. Weitere Informationen finden Sie im Abschnitt "Zuweisen von Bereichen für die manuelle Verwaltung von Identitätsbereichen" in "Replizieren von Identitätsspalten".

Funktionseinschränkungen

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

• Initialisierung und Erneute Initialisierung mit einer Momentaufnahme.

• Zeilen- und Spaltenfilter.

• Zeitstempelspalten.

• Nicht-SQL Server-Herausgeber und -Abonnenten.

• Sofortige Aktualisierung und in die Warteschlange eingereihte Aktualisierung von Abonnements.

• Anonyme Abonnements.

• Teilabonnements.

• Anhängbare Abonnements und transformierbare Abonnements. (Beide Optionen sind in SQL Server 2005 veraltet.)

• Geteilte Vertriebsagenten

• Der Distribution Agent-Parameter -SubscriptionStreams und der Log Reader Agent-Parameter -MaxCmdsInTran.

• Die Artikeleigenschaften @destination_owner und @destination_table.

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

Die folgenden Eigenschaften weisen besondere Überlegungen auf:

• Die Publikationseigenschaft @allow_initialize_from_backup erfordert einen Wert von true.

• Die Artikeleigenschaft @replicate_ddl erfordert einen Wert von true; @identityrangemanagementoption erfordert einen Wert von manual; und @status erfordert, dass Option 24 festgelegt ist.

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

• Die Abonnementeigenschaft @sync_type erfordert einen Wert von none oder automatic.

Überlegungen zur Wartung

Für die folgenden Aktionen muss das System in einen Ruhezustand versetzt werden. Dies bedeutet, dass Aktivitäten für veröffentlichte Tabellen auf allen Knoten gestoppt werden und sichergestellt wird, 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 Publikation

• Vornehmen von Schemaänderungen

• Wiederherstellen eines Knotens aus einer Sicherung

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

• Wenn Sie einer Peer-to-Peer-Topologie einen neuen Knoten hinzufügen, sollten Sie nur Sicherungen wiederherstellen, die nach dem Hinzufügen des neuen Knotens erstellt wurden.

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

Siehe auch

Verwalten einer Peer-zu-Peer-Topologie (Replikationsprogrammierung mit Transact-SQL)
Strategien zum Sichern und Wiederherstellen von Momentaufnahmen und Transaktionsreplikationen
Publikationstypen für die Transaktionsreplikation