Freigeben über


In die Warteschlange eingereihte Aktualisierung der Konflikterkennung und -lösung

Da die Aktualisierung von Abonnements mit Warteschlangen Änderungen an denselben Daten an mehreren Speicherorten zulässt, können Konflikte auftreten, wenn Daten beim Publisher synchronisiert werden. Replikation erkennt alle Konflikte, wenn Änderungen mit dem Publisher synchronisiert werden, und löst diese Konflikte mithilfe der Lösungsrichtlinie, die Sie beim Erstellen der Veröffentlichung ausgewählt haben. Die folgenden Konflikte können auftreten:

  • Aktualisieren und Einfügen von Konflikten. Dieser Konflikt tritt auf, wenn die gleichen Daten an zwei Speicherorten geändert werden. Eine Änderung gewinnt, und die andere verliert.

  • Konflikte löschen. Dieser Konflikt tritt auf, wenn die gleiche Zeile an einer Position gelöscht und an der anderen geändert wird.

Konflikterkennung und -lösung kann ein zeitaufwendiger und ressourcenintensiver Prozess sein; Daher empfiehlt es sich, Konflikte in der Anwendung zu minimieren, indem Datenpartitionen erstellt werden, sodass verschiedene Abonnenten unterschiedliche Teilmengen von Daten ändern.

Erkennen von Konflikten

Beim Erstellen einer Publikation und Aktivieren der Aktualisierung in Warteschlange fügt die Replikation der zugrunde liegenden Tabelle eine eindeutige Identifiziererspalte hinzu (msrepl_tran_version) mit der Standardeinstellung "newid()". Wenn veröffentlichte Daten entweder beim Publisher oder beim Abonnenten geändert werden, erhält die Zeile einen neuen GUID (Globally Unique Identifier), damit angezeigt wird, dass eine neue Zeilenversion vorhanden ist. Der Warteschlangenleser-Agent nutzt diese Spalte, um während der Synchronisierung festzustellen, ob ein Konflikt besteht.

Eine Transaktion in einer Warteschlange verwaltet die alten und neuen Zeilenversionswerte. Wenn die Transaktion beim Publisher angewendet wird, werden die GUIDs aus der Transaktion und der GUID in der Publikation verglichen. Wenn die in der Transaktion gespeicherte alte GUID mit der GUID in der Publikation übereinstimmt, wird die Publikation aktualisiert, und der Zeile wird die neue GUID zugewiesen, die vom Abonnenten generiert wurde. Durch das Aktualisieren der Publikation mit der GUID aus der Transaktion erhalten Sie entsprechende Zeilenversionen sowohl in der Publikation als auch in der Transaktion.

Wenn die in der Transaktion gespeicherte alte GUID nicht mit der GUID in der Publikation übereinstimmt, wird ein Konflikt erkannt. Die neue GUID in der Publikation gibt an, dass zwei verschiedene Zeilenversionen vorhanden sind: eine in der Transaktion, die vom Abonnenten übermittelt wird, und eine neuere, die in Publisher vorhanden ist. In diesem Fall hat ein anderer Abonnent oder Publisher die gleiche Zeile in der Publikation aktualisiert, bevor diese Abonnententransaktion synchronisiert wurde.

Im Gegensatz zur Zusammenführungsreplikation wird eine GUID-Spalte nicht verwendet, um die Zeile selbst zu identifizieren, sondern um zu überprüfen, ob sich die Zeile geändert hat.

Auflösen von Konflikten

Wenn Sie eine Publikation mithilfe der Aktualisierung durch Warteschlangeneinreihung erstellen, wählen Sie einen Konfliktlöser aus, der verwendet wird, wenn Konflikte erkannt werden. Der Konfliktlöser legt fest, wie der Warteschlangenlese-Agent während der Synchronisierung mit verschiedenen Versionen derselben Zeile umgeht. Sie können die Konfliktlösungsrichtlinie ändern, nachdem die Publikation erstellt wurde, solange keine Abonnements für die Publikation vorhanden sind. Die Konfliktlöseroptionen sind die folgenden:

  • Publisher gewinnt (Standard)

  • Publisher gewinnt und das Abonnement erneut initialisiert wird

  • Abonnentengewinne

Konflikte werden aufgezeichnet und können mithilfe der Konfliktanzeige angezeigt werden.

So legen Sie die Richtlinie zur Konfliktlösungsstrategie bei geplanten Updates fest

So zeigen Sie Datenkonflikte an

Verlag gewinnt

Wenn die Konfliktauflösung auf "Publisher wins" festgelegt ist, wird die Transaktionskonsistenz basierend auf den Daten beim Publisher beibehalten. Die widersprüchliche Transaktion wird beim Abonnenten zurückgesetzt, der sie initiiert hat.

Der Warteschlangenleser-Agent erkennt einen Konflikt und ausgleichende Befehle werden generiert und an den Abonnenten weitergegeben, indem sie in der Verteilungsdatenbank veröffentlicht werden. Der Verteilungs-Agent wendet dann die Ausgleichsbefehle auf den Abonnenten an, der die widersprüchliche Transaktion verursacht hat. Die Ausgleichsaktionen aktualisieren die Zeilen des Abonnenten, um sie mit den Zeilen des Herausgebers abzugleichen.

Bis die Ausgleichsbefehle angewendet werden, ist es möglich, die Ergebnisse einer Transaktion zu lesen, die letztendlich beim Abonnenten zurückgesetzt wird. Dies entspricht einem Dirty Read (Isolationsebene "Lesen nicht bestätigt"). Es gibt keine Entschädigung für die nachfolgenden abhängigen Transaktionen, die auftreten können. Jedoch werden Transaktionsgrenzen berücksichtigt, und alle Aktionen innerhalb einer Transaktion werden entweder festgeschrieben oder im Falle eines Konflikts rückgängig gemacht.

Der Publisher gewinnt und das Abonnement wird neu initialisiert

Durch erneutes Initialisieren des Abonnenten zum Lösen von Konflikten bleibt die strikte Transaktionskonsistenz beim Abonnenten erhalten, kann aber zeitaufwändig sein, wenn die Publikation große Datenmengen enthält.

Wenn der Warteschlangenleser-Agent einen Konflikt erkennt, werden alle verbleibenden Transaktionen in der Warteschlange (einschließlich der Transaktion in Konflikt) abgelehnt, und der Abonnent wird für die Erneute Initialisierung markiert. Der nächste für die Publikation erzeugte Snapshot wird vom Distributions-Agent auf den Empfänger angewendet.

Erfolge von Abonnenten

Die Konflikterkennung gemäß der Richtlinie "Subscriber wins" bedeutet, dass die letzte Abonnententransaktion, die den Publisher aktualisiert, gewinnt. Wenn ein Konflikt erkannt wird, wird die vom Abonnenten gesendete Transaktion weiterhin verwendet, und der Herausgeber wird aktualisiert. Diese Richtlinie eignet sich für Anwendungen, bei denen solche Änderungen die Datenintegrität nicht gefährden.

Siehe auch

Aktualisierbare Abonnements für Transaktionsreplikation