(0) exportieren Drucken
Alle erweitern

Konflikterkennung bei der Peer-to-Peer-Replikation

Bei der Peer-to-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 die Aktualisierung kann sogar verloren gehen, wenn die Zeile an andere Knoten übermittelt wird.

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. Mithilfe dieser Option kann Problemen vorgebeugt werden, die durch nicht erkannte Konflikte, einschließlich inkonsistentem Verhalten von Anwendungen und verlorenen Aktualisierungen, entstehen. 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.

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 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 (Übersicht) und Erkennen und Beseitigen von Konflikten bei der Mergereplikation.

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-to-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-to-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-to-Peer-Replikation werden Konflikte von den gespeicherten Prozeduren erkannt, die Änderungen an jedem Knoten übernehmen, und zwar basierend auf einer ausgeblendeten Spalte in jeder veröffentlichten Tabelle. 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. 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 des Werts der ausgeblendeten Spalte einen Konflikt erkennt, wird Fehler 22815 mit einem Schweregrad von 16 ausgelöst:

Ein Konflikt vom Typ '%s' wurde auf dem Peer %d zwischen dem Peer %d (eingehend), Transaktions-ID %s, und dem Peer %d (auf dem Datenträger), Transaktions-ID %s, erkannt.

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 "Konfliktbehandlung" weiter unten in diesem Thema.

HinweisHinweis

Der Zugriff auf die ausgeblendete Spalte ist nur durch einen Benutzer möglich, der sich über die dedizierte Administratorverbindung (DAC) angemeldet hat. Informationen zu DAC finden Sie unter Verwenden einer dedizierten Administratorverbindung.

Die Peer-to-Peer-Replikation erkennt die folgenden Typen von Konflikten:

  • Insert-insert

    Alle Zeilen in einer Tabelle, die an der Peer-to-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.

Zur Verwendung der Konflikterkennung muss auf allen Knoten SQL Server 2008 oder eine höhere Version ausgeführt werden, und die Erkennung muss für alle Knoten aktiviert sein. In SQL Server 2008 und höheren Versionen ist die Konflikterkennung in SQL Server Management Studio standardmäßig aktiviert. Es wird empfohlen, die Konflikterkennung auch in Szenarien zu aktivieren, in denen Sie keine Konflikte erwarten. Die Konflikterkennung kann in Management Studio oder mithilfe der gespeicherten Prozeduren in Transact-SQL aktiviert und deaktiviert werden:

Wenn ein Konflikt in der Peer-to-Peer-Replikation auftritt, wird die Peer-to-Peer Konflikterkennungswarnung ausgelöst. Es wird empfohlen, diese Warnung so zu konfigurieren, dass Sie benachrichtigt werden, wenn ein Konflikt auftritt. Weitere Informationen zu Warnungen finden Sie unter Verwenden von Warnungen für Ereignisse des Replikations-Agents.

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. Weitere Informationen finden Sie in der Vorgehensweise zum Hinzufügen eines Knotens zu einer Topologie unter Vorgehensweise: Konfigurieren der Peer-to-Peer-Transaktionsreplikation (Replikationsprogrammierung mit Transact-SQL).

  • Versuchen Sie, den Knoten wieder zu synchronisieren, indem Sie den Verteilungs-Agent aktivieren, damit dieser das Übernehmen von Änderungen fortsetzt:

    1. Führen Sie sp_changepublication aus: Geben Sie 'p2p_continue_onconflict' für den @property-Parameter und true für den @value-Parameter an.

    2. Starten Sie den Verteilungs-Agent neu.

    3. Ü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 Vorgehensweise: Anzeigen von Datenkonflikten für Transaktionsveröffentlichungen (SQL Server Management Studio).

    4. 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.

      HinweisHinweis

      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.

    5. Führen Sie sp_changepublication aus: Geben Sie 'p2p_continue_onconflict' für den @property-Parameter und false für den @value-Parameter an.

Community-Beiträge

HINZUFÜGEN
Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur MSDN-Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die MSDN-Website verlassen.

Möchten Sie an der Umfrage teilnehmen?
Anzeigen:
© 2014 Microsoft