Teilen über

Konflikterkennung und -lösung bei der Mergereplikation

Die Mergereplikation ermöglicht es mehreren Knoten, autonome Datenänderungen vorzunehmen, so dass Situationen entstehen können, in denen eine Änderung, die an einem Knoten vorgenommen wurde, zu einem Konflikt mit einer Änderung führen könnte, die an denselben Daten an einem anderen Knoten vorgenommen wurde. In anderen Situationen tritt bei dem Zusammenführungs-Agent ein Fehler auf, z. B., eine Einschränkungsverletzung, und eine an einem bestimmten Knoten vorgenommene Änderung kann nicht auf einen anderen Knoten übertragen werden. In diesem Artikel werden Arten von Konflikten beschrieben, wie Konflikte erkannt und aufgelöst werden, sowie Faktoren, die sich auf die Erkennung und Lösung auswirken.

Erkennen und Beheben von Konflikten

Der Zusammenführungs-Agent erkennt Konflikte mithilfe der lineage Spalte der MSmerge_contents Systemtabelle. Wenn die Nachverfolgung auf Spaltenebene für einen Artikel aktiviert ist, wird auch die COLV1 Spalte verwendet. Diese Spalten enthalten Metadaten darüber, wann eine Zeile oder Spalte eingefügt oder aktualisiert wird und welche Knoten in einer Zusammenführungsreplikationstopologie Änderungen an der Zeile oder Spalte vorgenommen haben. Sie können die sp_showrowreplicainfo gespeicherten Systemprozedur verwenden, um diese Metadaten anzuzeigen.

Wenn der Zusammenführungs-Agent Änderungen aufzählt, die während der Synchronisierung angewendet werden sollen, vergleicht er die Metadaten für jede Zeile zwischen dem Herausgeber und dem Abonnenten. Der Zusammenführungs-Agent verwendet diese Metadaten, um zu ermitteln, ob sich eine Zeile oder Spalte in mehr als einem Knoten in der Topologie geändert hat, was einen potenziellen Konflikt angibt. Nachdem ein Konflikt erkannt wurde, startet der Zusammenführungs-Agent den für den Artikel mit einem Konflikt angegebenen Konfliktlöser und verwendet den Resolver, um den Konfliktgewinner zu ermitteln. Die gewinnbringende Zeile wird beim Herausgeber und Abonnenten angewendet, und die Daten aus der verlorenen Zeile werden in eine Konflikttabelle geschrieben.

Konflikte werden automatisch und sofort vom Merge-Agent aufgelöst; es sei denn, Sie haben die interaktive Konfliktlösung für den Artikel ausgewählt. Weitere Informationen finden Sie unter Microsoft Replication Interactive Conflict Resolver. Wenn Sie die „gewinnende“ Zeile in einem Konflikt manuell mithilfe des Mergereplikationskonflikt-Viewers ändern, wendet der Merge-Agent diese Version der Zeile während der nächsten Synchronisierung auf dem „unterlegenen“ Server an.

Gelöste Konflikte protokollieren

Nachdem der Zusammenführungs-Agent den Konflikt gemäß der Logik im Konfliktlöser gelöst hat, protokolliert er Konfliktdaten gemäß dem Typ des Konflikts:

  • Für UPDATE- und INSERT-Konflikte schreibt es die verlierende Version der Zeile in die Konflikttabelle des Artikels, die in der Form conflict_<PublicationName>_<ArticleName> benannt ist. Die allgemeinen Konfliktinformationen, z. B. der Typ des Konflikts, werden in die Tabelle MSmerge_conflicts_infogeschrieben.

  • Bei DELETE Konflikten schreibt sie die verlorene Version der Zeile in die MSmerge_conflicts_info Tabelle. Wenn ein Löschvorgang gegen eine Aktualisierung „verliert“, gibt es keine Daten für die „unterlegene“ Zeile (da es sich eben um einen Löschvorgang handelt), so dass nichts in conflict_<PublicationName>_<ArticleName> geschrieben wird.

Die Konflikttabellen für jeden Artikel werden in der Publikationsdatenbank, in der Abonnementdatenbank oder in beiden (standard) erstellt, je nach dem für den @conflict_logging Parameter angegebenen Wert.sp_addmergepublication Jede Konflikttabelle hat die gleiche Struktur wie der Artikel, auf dem sie basiert, mit dem Hinzufügen der origin_datasource_id Spalte. Der Zusammenführungs-Agent löscht Daten aus der Konflikttabelle, wenn er älter als der Konfliktaufbewahrungszeitraum für die Publikation ist, der mit dem @conflict_retention Parameter sp_addmergepublication angegeben wird (der Standardwert ist 14 Tage).

Replikation stellt den Replikationskonflikt-Viewer und gespeicherte Prozeduren (sp_helpmergearticleconflicts, sp_helpmergeconflictrowsund sp_helpmergedeleteconflictrows) zum Anzeigen von Konfliktdaten bereit. Weitere Informationen finden Sie unter Auflösung von Konflikten bei der Mergereplikation.

Faktoren, die sich auf die Konfliktlösung auswirken

Es gibt zwei Faktoren, die sich darauf auswirken, wie der Zusammenführungs-Agent einen erkannten Konflikt löst:

  • Der Typ des Abonnements: Client oder Server (unabhängig davon, ob es sich bei dem Abonnement um ein Pullabonnement oder ein Pushabonnement handelt, wirkt sich nicht auf die Konfliktauflösung aus).

  • Der Typ der verwendeten Konfliktnachverfolgung: Zeilenebene, Spaltenebene oder logische Datensatzebene.

Abonnementtypen

Wenn Sie ein Abonnement erstellen, müssen Sie zusätzlich angeben, ob es sich um ein Push- oder Pullabonnement handelt, ob es sich um ein Client- oder Serverabonnement handelt. Nachdem ein Abonnement erstellt wurde, kann der Typ nicht geändert werden (in früheren Versionen von SQL Server wurden Client- und Serverabonnements als lokale und globale Abonnements bezeichnet).

Ein Abonnement mit einem zugewiesenen Prioritätswert (von 0,00 bis 99.99) wird als Serverabonnement bezeichnet. ein Abonnement, das den Prioritätswert von Publisher verwendet, wird als Clientabonnement bezeichnet. Darüber hinaus können Abonnenten mit Serverabonnements Daten für andere Abonnenten erneut veröffentlichen. In der folgenden Tabelle sind die wichtigsten Unterschiede und Verwendungen der einzelnen Abonnententypen zusammengefasst.

Typ Prioritätswert Verwendet
Server Zugewiesen vom Benutzer Wenn Sie möchten, dass verschiedene Abonnenten unterschiedliche Prioritäten haben.
Kunde 0,00, aber nach der Synchronisierung übernehmen Datenänderungen den Prioritätswert des Publisher. Wenn Sie möchten, dass alle Abonnenten die gleiche Priorität haben, und der erste Abonnent, der mit dem Publisher zusammengeführt wird, den Konflikt „gewinnt“.

Wenn eine Zeile in einem Clientabonnement geändert wird, wird der Änderung keine Priorität zugewiesen, bis das Abonnement synchronisiert wird. Während der Synchronisierung werden den Änderungen des Abonnenten die Priorität des Herausgebers zugewiesen und diese Priorität für nachfolgende Synchronisierungen beibehalten. In gewisser Weise übernimmt der Verleger die Verantwortung für die Änderung. Dieses Verhalten ermöglicht es dem ersten Abonnenten, mit dem Publisher zu synchronisieren, um nachfolgende Konflikte mit anderen Abonnenten für eine bestimmte Zeile oder Spalte zu gewinnen.

Wenn Sie eine Zeile in einem Serverabonnement ändern, wird die Abonnementpriorität in den Metadaten für die Änderung gespeichert. Dieser Prioritätswert wird mit der geänderten Zeile transportiert, während sie mit Änderungen bei anderen Abonnenten zusammengeführt wird. Dadurch wird sichergestellt, dass eine Änderung, die von einem Abonnement mit höherer Priorität vorgenommen wurde, nicht an eine nachfolgende Änderung verloren geht, die von einem Abonnement mit einer niedrigeren Priorität vorgenommen wurde.

Ein Abonnement kann keinen expliziten Prioritätswert haben, der höher als sein Publisher ist. Der Publisher auf oberster Ebene in einer Mergereplikationstopologie hat immer den expliziten Prioritätswert 100.00. Alle Abonnements für diese Publikation müssen einen Prioritätswert haben, der kleiner als dieser Wert ist. In einer Topologie für erneute Veröffentlichungen:

  • Wenn der Abonnent Daten erneut veröffentlicht, muss das Abonnement ein Serverabonnement mit einem Prioritätswert sein, der kleiner als der Herausgeber über dem Abonnenten ist.

  • Wenn der Abonnent die Daten nicht erneut veröffentlicht (da er sich auf der Blattebene der Struktur für erneute Veröffentlichungen befindet), muss es sich bei dem Abonnement um ein Client-Abonnement handeln.

Weitere Informationen zu Serverabonnements und -prioritäten finden Sie unter "Beispiel für die Konfliktlösung beim Zusammenführen" auf Basis des Abonnementtyps und der zugewiesenen Prioritäten.

Verzögerte Konfliktbenachrichtigung

Eine verzögerte Konfliktbenachrichtigung kann mit Serverabonnements auftreten, die unterschiedliche Konfliktprioritäten aufweisen. Betrachten Sie das folgende Szenario, in dem nicht widersprüchliche Änderungen zwischen Publisher und einem Abonnenten mit niedrigerer Priorität ausgetauscht werden, die zu widersprüchlichen Änderungen führen, wenn ein Abonnent mit höherer Priorität mit publisher synchronisiert wird:

  1. Der Herausgeber und ein Abonnent mit niedriger Priorität namens LowPrioritySub tauschen Änderungen über mehrere Synchronisierungen ohne Konflikt aus.

  2. Ein Abonnent mit höherer Priorität, namens HighPrioritySub, wurde seit einiger Zeit nicht mit dem Publisher synchronisiert und hat Änderungen an denselben Zeilen vorgenommen, die der LowPrioritySub Abonnent vorgenommen hat.

  3. Der HighPrioritySub Subscriber synchronisiert mit dem Herausgeber und gewinnt die Konflikte zwischen seinen Änderungen und dem LowPrioritySub Subscriber, da er eine höhere Priorität als der LowPrioritySub Subscriber hat. Das Publisher enthält jetzt die Änderungen, die vom HighPrioritySub-Abonnent vorgenommen wurden.

  4. Der LowPrioritySub-Abonnent wird dann mit dem Publisher zusammengeführt und lädt aufgrund der Konflikte mit dem HighPrioritySub-Abonnenten eine große Anzahl von Änderungen herunter.

Diese Situation kann zu Problemen führen, wenn der Abonnent mit niedrigerer Priorität Änderungen an denselben Zeilen vorgenommen hat, die jetzt „Unterlegene“ in dem Konflikt sind. Dies kann zu einem Verlust aller Änderungen führen, die von diesem Abonnenten vorgenommen wurden. Eine mögliche Lösung für dieses Problem besteht darin, sicherzustellen, dass alle Abonnenten die gleiche Priorität haben, es sei denn, geschäftslogik diktiert andernfalls.

Nachverfolgungsebene

Ob eine Datenänderung als Konflikt qualifiziert ist, hängt vom Typ der Konfliktnachverfolgung ab, die Sie für einen Artikel festgelegt haben: Zeilenebene, Spaltenebene oder logische Datensatzebene. Weitere Informationen zur Nachverfolgung auf logischer Datensatzebene finden Sie unter Advanced Merge Replication Conflict – Resolving in Logical Record.

Wenn Konflikte auf Zeilenebene erkannt werden, werden Änderungen, die an entsprechenden Zeilen vorgenommen wurden, als Konflikt beurteilt, unabhängig davon, ob die Änderungen an derselben Spalte vorgenommen werden. Angenommen, eine Änderung wird an der Adressspalte einer Publisher-Zeile vorgenommen, und eine zweite Änderung wird an der Telefonnummernspalte der entsprechenden Zeile "Abonnenten" (in derselben Tabelle) vorgenommen. Bei der Nachverfolgung auf Zeilenebene wird ein Konflikt erkannt, da Änderungen an derselben Zeile vorgenommen wurden. Bei der Nachverfolgung auf Spaltenebene wird kein Konflikt erkannt, da Änderungen an verschiedenen Spalten in derselben Zeile vorgenommen wurden.

Für die Nachverfolgung auf Zeilen- und Spaltenebene ist die Auflösung des Konflikts identisch: Die gesamte Datenzeile wird von Daten vom Konfliktgewinner überschrieben (für die Nachverfolgung auf logischer Datensatzebene hängt die Auflösung von der Artikeleigenschaft logical_record_level_conflict_resolutionab).

Die Anwendungssemantik bestimmt in der Regel, welche Nachverfolgungsoption verwendet werden soll. Wenn Sie beispielsweise Kundendaten aktualisieren, die in der Regel gleichzeitig eingegeben werden, z. B. eine Adresse und Telefonnummer, sollte die Nachverfolgung auf Zeilenebene ausgewählt werden. Wenn in dieser Situation die Nachverfolgung auf Spaltenebene ausgewählt wurde, werden Änderungen an der Kundenadresse an einem Ort und an der Kundentelefonnummer an einem anderen Ort nicht als Konflikt erkannt: Die Daten werden bei der Synchronisierung zusammengeführt, und der Fehler würde verpasst. In anderen Situationen ist das Aktualisieren einzelner Spalten aus verschiedenen Websites möglicherweise die logischste Wahl. Beispielsweise können zwei Websites Zugriff auf verschiedene Arten von statistischen Informationen für einen Kunden haben, z. B. Einkommensniveau und Gesamtbetrag der Kreditkartenkäufe. Durch auswählen der Nachverfolgung auf Spaltenebene wird sichergestellt, dass beide Websites die statistischen Daten für unterschiedliche Spalten eingeben können, ohne unnötige Konflikte zu generieren.

Hinweis

Wenn Ihre Anwendung keine Nachverfolgung auf Spaltenebene erfordert, empfiehlt es sich, die Nachverfolgung auf Zeilenebene (Standardeinstellung) zu verwenden, da dies in der Regel zu einer besseren Synchronisierungsleistung führt. Wenn die Zeilennachverfolgung verwendet wird, kann die Basistabelle maximal 1.024 Spalten enthalten, aber Spalten müssen aus dem Artikel gefiltert werden, sodass maximal 246 Spalten veröffentlicht werden. Wenn Spaltennachverfolgung verwendet wird, kann die Basistabelle maximal 246 Spalten enthalten.

Konflikttypen

Obwohl die meisten Konflikte mit Updates zusammenhängen (ein Update an einem Knoten steht in Konflikt mit einem Update oder Löschen bei einem anderen Knoten), gibt es andere Konflikttypen. Jeder in diesem Abschnitt beschriebene Konflikttyp kann während der Uploadphase oder der Downloadphase der Zusammenführungsverarbeitung auftreten. Die Uploadverarbeitung ist die erste Abstimmung von Änderungen, die in einer bestimmten Zusammenführungssitzung durchgeführt wurden, und ist die Phase, in der der Zusammenführungs-Agent Änderungen vom Abonnenten bis zum Publisher repliziert. Konflikte, die während dieser Verarbeitung erkannt wurden, werden als Uploadkonflikte bezeichnet. Die Downloadverarbeitung umfasst das Verschieben von Änderungen von dem Herausgeber zu dem Abonnenten und erfolgt nach der Uploadverarbeitung. Konflikte während dieser Verarbeitungsphase werden als Downloadkonflikte bezeichnet.

Weitere Informationen zu Konflikttypen finden Sie unter MSmerge_conflicts_info, insbesondere in den Spalten conflict_type und reason_code.

Update-Update-Konflikte

Der Zusammenführungs-Agent erkennt Aktualisierungskonflikte, wenn eine Aktualisierung einer Zeile (oder Spalte oder eines logischen Datensatzes) bei einem Knoten mit einer anderen Aktualisierung auf dieselbe Zeile an einem anderen Knoten in Konflikt steht. Das Verhalten des Standardlösers in diesem Fall besteht darin, die gewinnbringende Version der Zeile an den Verlustknoten zu senden und die Verlustzeilenversion in der Artikelkonflikttabelle zu protokollieren.

Konflikte bei Aktualisierung und Löschung

Der Zusammenführungs-Agent erkennt Konflikte zwischen Aktualisierung und Löschung, wenn eine Datenaktualisierung an einem Knoten einem Löschvorgang an einem anderen Knoten widerspricht. In diesem Fall aktualisiert der Zusammenführungs-Agent eine Zeile; wenn der Zusammenführungs-Agent jedoch nach dieser Zeile am Ziel sucht, kann er die Zeile nicht finden, weil sie gelöscht wurde. Wenn der Gewinner der Knoten ist, der die Zeile aktualisiert hat, wird der Löschvorgang beim verlierenden Knoten verworfen, und der Konfliktauflösungs-Agent sendet die aktualisierte Zeile an den Konfliktverlierer. Der Merge-Agent protokolliert Informationen über die „unterlegene“ Version der Zeile in der MSmerge_conflicts_info-Tabelle.

Fehlgeschlagene Änderungskonflikte

Der Merge-Agent meldet diese Konflikte, wenn eine bestimmte Änderung nicht angewendet werden kann. Dies tritt in der Regel aufgrund eines Unterschieds bei Einschränkungsdefinitionen zwischen Publisher und Subscriber und der Verwendung der NOT FOR REPLICATION NFR-Eigenschaft für die Einschränkung auf. Beispiele sind:

  • Ein Fremdschlüsselkonflikt beim Abonnenten, der auftreten kann, wenn die abonnentenseitige Einschränkung nicht als NFR markiert ist.

  • Unterschiede bei Einschränkungen zwischen Publisher und Abonnenten, und die Einschränkungen werden nicht als NFR gekennzeichnet.

  • Die Nichtverfügbarkeit abhängiger Objekte beim Abonnenten. Wenn Sie beispielsweise eine Ansicht veröffentlichen, aber nicht die Tabelle, von der diese Ansicht abhängt, tritt ein Fehler auf, wenn Sie versuchen, durch diese Ansicht beim Abonnenten Daten einzufügen.

  • Verknüpfungsfilterlogik für eine Publikation, die nicht den Einschränkungen für Primär- und Fremdschlüssel entspricht. Konflikte können auftreten, wenn das relationale SQL Server-Modul versucht, eine Einschränkung zu berücksichtigen, aber der Merge-Agent berücksichtigt die Verknüpfungsfilterdefinition zwischen den Artikeln. Der Zusammenführungs-Agent kann die Änderung am Zielknoten aufgrund der Einschränkungen auf Tabellenebene nicht anwenden, was zu einem Konflikt führt.

  • Konflikte aufgrund eindeutiger Index- oder eindeutiger Einschränkungsverletzungen oder Primärschlüsselverletzungen können auftreten, wenn Identitätsspalten für den Artikel definiert sind und die automatisierte Identitätsverwaltung nicht verwendet wird. Dies kann ein Problem sein, wenn zwei Abonnenten denselben Identitätswert für eine neu eingefügte Zeile verwenden würden. Weitere Informationen zur Verwaltung von Identitätsbereichen finden Sie unter Replizieren von Identitätsspalten.

  • Konflikte aufgrund von Triggerlogik verhindern, dass der Merge-Agent eine Zeile in die Zieltabelle einfügt. Erwägen Sie einen Updatetrigger, der beim Abonnenten definiert ist; der Trigger ist nicht als NFR gekennzeichnet und enthält eine ROLLBACK in seiner Logik. Wenn ein Fehler auftritt, führt der Trigger ein ROLLBACK der Transaktion aus, was dazu führt, dass der Zusammenführungs-Agent einen fehlgeschlagenen Änderungs-Konflikt erkennt.

Verwandte Inhalte

  • Last updated on