Peer-zu-Peer – Konflikterkennung bei der Peer-zu-Peer-Replikation
Gilt für: 
SQL Server
Bei der Peer-zu-Peer-Transaktionsreplikation können Sie an einem beliebigen Knoten in der Topologie Daten einfügen, aktualisieren oder löschen, und Datenänderungen können an andere Knoten übermittelt werden. Da Sie Daten an einem beliebigen Knoten ändern können, können Datenänderungen an verschiedenen Knoten untereinander in Konflikt stehen. 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.
Die Peer-zu-Peer-Replikation bietet die Option, die Konflikterkennung für eine gesamte Peer-zu-Peer-Topologie zu aktivieren. Diese Option hilft, den Problemen vorzubeugen, die sich aus nicht erkannten Konflikten wie dem inkonsistenten 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 gelöst und die Datenkonsistenz in der Topologie wiederhergestellt wurde.
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 stammt, 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.
Grundlegendes zu Konflikten und zur Konflikterkennung
In einer einzelnen Datenbank verursachen Änderungen, die von verschiedenen Anwendungen an derselben Zeile vorgenommen werden, keinen Konflikt. Der Grund dafür ist, dass Transaktionen serialisiert und gleichzeitige Änderungen mithilfe von Sperren behandelt werden. In einem asynchronen verteilten System wie der Peer-zu-Peer-Replikation agieren Transaktionen unabhängig voneinander auf jedem Knoten, und es gibt keinen Mechanismus dafür, Transaktionen über mehrere Knoten zu serialisieren. Ein Protokoll wie Zweiphasencommit könnte verwendet werden, aber dies hat deutliche Auswirkungen auf die Leistung.
In Systemen wie der Peer-zu-Peer-Replikation werden Konflikte nicht erkannt, wenn für Änderungen ein Commit auf einzelnen Peers ausgeführt wird. Sie werden erst erkannt, wenn diese Änderungen repliziert und auf anderen Peers übernommen werden. Bei der Peer-zu-Peer-Replikation werden Konflikte von den gespeicherten Prozeduren erkannt, die Änderungen auf die einzelnen Knoten anwenden, und zwar basierend auf mindestens einer ausgeblendeten Spalte in den einzelnen veröffentlichten Tabellen.
Vor SQL Server 2019 (15.x) CU 13 fügt SQL Server jeder veröffentlichten Tabelle eine ausgeblendete Spalte hinzu: $sys_p2p_cd_id. In dieser ausgeblendeten Spalte ist eine ID gespeichert, die eine Absender-ID , die Sie für jeden Knoten angeben, mit der Version der Zeile kombiniert.
Wenn Sie in SQL Server 2019 (15.x) CU 13 und höher die Peer-zu-Peer-Veröffentlichung über @p2p_conflictdetection_policy = 'lastwriter' erstellen, fügt SQL Server jeder veröffentlichten Tabelle eine zusätzliche ausgeblendete Spalte hinzu: $sys_md_cd_id. In dieser ausgeblendeten Spalte wird der datetime-Wert als datetime2-Datentyp gespeichert.
Während der Synchronisierung führt der Verteilungs-Agent Prozeduren für jede Tabelle aus. Diese Prozeduren übernehmen Einfüge-, Update- und Löschvorgänge von anderen Peers. Wenn eine der Prozeduren beim Lesen der Werte der ausgeblendeten Spalten einen Konflikt erkennt, wird Fehler 22815 mit einem Schweregrad von 16 ausgelöst:
A conflict of type '%s' was detected at peer %d between peer %d (incoming), transaction id %s and peer %d (on disk), transaction id %s
Standardmäßig führt dieser Fehler dazu, dass der Verteilungs-Agent das Übernehmen von Änderungen für diesen Knoten beendet. Informationen zum Behandeln der erkannten Konflikte finden Sie unter Behandeln von Konflikten.
Hinweis
Der Zugriff auf die ausgeblendete Spalte ist nur durch einen Benutzer möglich, der sich über die dedizierte Administratorverbindung (DAC) angemeldet hat. Weitere Informationen zu DAC finden Sie unter Diagnoseverbindung für Datenbankadministratoren.
Die Peer-zu-Peer-Replikation erkennt die folgenden Typen von Konflikten:
Insert-insert
Alle Zeilen in einer Tabelle, die an der Peer-zu-Peer-Replikation beteiligt sind, werden mithilfe von Primärschlüsselwerten eindeutig identifiziert. Ein Konflikt vom Typ "insert-insert" tritt auf, wenn eine Zeile mit demselben Schlüsselwert an mehreren Knoten eingefügt wurde.
Update-update
Tritt auf, wenn eine Zeile an mehreren Knoten aktualisiert wurde.
Insert-update
Tritt auf, wenn eine Zeile an einem Knoten aktualisiert wurde, diese Zeile aber gelöscht und dann an einem anderen Knoten erneut eingefügt wurde.
Insert-delete
Tritt auf, wenn eine Zeile an einem Knoten gelöscht wurde, diese Zeile aber gelöscht und dann an einem anderen Knoten erneut eingefügt wurde.
Update-delete
Tritt auf, wenn eine Zeile an einem Knoten aktualisiert wurde, diese Zeile aber an einem anderen Knoten gelöscht wurde.
Delete-delete
Tritt auf, wenn eine Zeile an mehreren Knoten gelöscht wurde.
Aktivieren der Konflikterkennung
Um die Konflikterkennung zu verwenden, aktivieren Sie die Erkennung für alle Knoten. Standardmäßig ist die Konflikterkennung aktiviert, wenn Sie die Peer-zu-Peer-Replikation in SQL Server Management Studio konfigurieren. Es wird empfohlen, die Konflikterkennung auch in Szenarien zu aktivieren, in denen Sie keine Konflikte erwarten. Die Konflikterkennung kann mithilfe der gespeicherten Prozeduren in Management Studio oder Transact-SQL aktiviert und deaktiviert werden:
Sie können die Konflikterkennung in Management Studio entweder auf der Seite Abonnementoptionen im Dialogfeld Veröffentlichungseigenschaften oder auf der Seite Topologie konfigurieren des Assistenten zum Konfigurieren der Peer-zu-Peer-Topologie aktivieren und deaktivieren.
Wenn Sie die Konflikterkennung mithilfe von Management Studio konfigurieren, wird der Verteilungs-Agent so konfiguriert, dass er bei Erkennung eines Konflikts das Übernehmen von Änderungen beendet.
Sie können die Erkennung auch anhand folgender gespeicherter Prozeduren aktivieren und deaktivieren:
sp_configure_peerconflictdetection.
Wenn Sie die Konflikterkennung mithilfe gespeicherter Prozeduren konfigurieren, können Sie angeben, ob der Verteilungs-Agent bei Erkennung eines Konflikts das Übernehmen von Änderungen beenden soll. Standardmäßig beendet der Agent diese Aufgabe. Es wird empfohlen, die Standardeinstellung zu verwenden.
Behandeln von Konflikten
Wenn bei der Peer-zu-Peer-Replikation ein Konflikt auftritt, wird die Peer-zu-Peer Konflikterkennungswarnung ausgelöst. Konfigurieren Sie diese Warnung so, dass Sie bei Auftreten eines Konflikts benachrichtigt werden. Weitere Informationen über Warnungen finden Sie unter Verwenden von Warnungen für Replikations-Agentereignisse.
Verwenden Sie eine der folgenden Vorgehensweisen, um den aufgetretenen Konflikt zu behandeln, nachdem der Verteilungs-Agent beendet und die Warnung ausgelöst wurde:
Initialisieren Sie den Knoten, an dem der Konflikt erkannt wurde, erneut aus der Sicherung eines Knotens, der die erforderlichen Daten aufweist (empfohlene Vorgehensweise). Mithilfe dieser Methode wird sichergestellt, dass sich die Daten in einem konsistenten Status befinden.
Versuchen Sie, den Knoten wieder zu synchronisieren, indem Sie den Verteilungs-Agent aktivieren, damit dieser das Übernehmen von Änderungen fortsetzt:
Führen Sie sp_changepublication aus: Geben Sie 'p2p_continue_onconflict' für den @property-Parameter und true für den @value-Parameter an.
Starten Sie den Verteilungs-Agent neu.
Überprüfen Sie die erkannten Konflikte im Konflikt-Viewer, und bestimmen Sie die beteiligten Zeilen, den Konflikttyp und den Gewinner. Der Konflikt wird anhand des Werts der Absender-ID aufgelöst, den Sie während der Konfiguration angegeben haben: Die Zeile, die von dem Knoten mit der höchsten ID stammt, gewinnt den Konflikt. Weitere Informationen finden Sie unter Anzeigen von Datenkonflikten für Transaktionsveröffentlichungen (SQL Server Management Studio).
Führen Sie eine Überprüfung aus, um sicherzustellen, dass die miteinander in Konflikt stehenden Zeilen ordnungsgemäß konvergiert wurden. Weitere Informationen finden Sie unter Überprüfen von replizierten Daten.
Hinweis
Wenn die Daten nach Ausführung dieses Schritts inkonsistent sind, müssen Sie die Zeilen auf dem Knoten mit der höchsten Priorität manuell aktualisieren und dann die Änderungen von diesem Knoten übertragen. Wenn die Topologie keine weiteren miteinander in Konflikt stehenden Änderungen aufweist, werden alle Knoten in einen konsistenten Status gebracht.
Führen Sie sp_changepublication aus: Geben Sie 'p2p_continue_onconflict' für den @property-Parameter und false für den @value-Parameter an.
Automatisches Behandeln von Konflikten über „Last Write Wins“ (letzter Schreibvorgang gewinnt)
Ab SQL Server 2019 (15.x) CU 13 können Sie die Peer-zu-Peer-Replikation so konfigurieren, dass Konflikte automatisch gelöst werden, indem die letzte Einfügung oder Aktualisierung den Konflikt gewinnt. Wenn ein Schreibvorgang die Zeile löscht, lässt SQL Server zu, dass der Löschvorgang den Konflikt gewinnt. Diese Methode wird als „last write wins“ (letzter Schreibvorgang gewinnt) bezeichnet.
Verwenden Sie gespeicherte Prozeduren, um den letzten Schreibvorgang zu konfigurieren. Informationen hierzu finden Sie unter Konfigurieren der Konflikterkennung und -lösung durch letzten Schreibvorgang. Sie können Last Write Wins nicht über SQL Server Management Studio konfigurieren.
Hinweis
Die Zuverlässigkeit der Peer-zu-Peer-Replikation mit „Last Write Wins“ hängt davon ab, dass die Uhren der beteiligten Knoten synchron sind. Wenn die Uhren der beteiligten Server zu weit voneinander abweichen, kann dies zu unerwarteten und/oder unerwünschten Ergebnissen führen. Wenn Server A beispielsweise über eine genaue Uhrzeit verfügt, Server B hingegen eine Woche zurückliegt, gewinnt Server A selbst dann jeden Konflikt, wenn er die Zeile objektiv gesehen nicht als Letzter aktualisiert hat. Wenn es nicht möglich ist, die Uhren innerhalb des Toleranzbereichs zu halten, den Sie für die Ergebnisauflösung benötigen, sollten Sie eine andere Konfliktlösungsstrategie wählen.