Voorbeeld van conflictoplossing samenvoegen op basis van abonnementstype en toegewezen prioriteiten

Als u wilt weten hoe conflicten worden opgelost op basis van toegewezen prioriteitswaarden en of een abonnement een server- of clientabonnement is, kunt u het volgende voorbeeld overwegen, waarin een reeks updates voor een rij wordt beschreven via verschillende samenvoegsynchronisaties.

Hier volgen de eerste prioriteitswaarden voor vier sites in een basistopologie voor samenvoegingsreplicatie (één uitgever, twee abonnees met serverabonnementen en één abonnee met een clientabonnement).

Fase 1: Initiële waarden

In eerste instantie maakt Site A (de uitgever) versie één van de rij met de waarde ='Nebraska', die wordt gerepliceerd naar Sites B, C en D tijdens de volgende samenvoegsynchronisatie. Na synchronisatie zijn dit de waarden voor de rij.

Fase 2: Uitgever en abonnee met serverabonnement beide rij bijwerken

Site A werkt de rijwaarde bij naar Texas en Site B werkt de rijwaarde bij naar New Jersey. Wanneer de volgende samenvoegsynchronisatie plaatsvindt, is er een conflict tussen sites A en B. Site A wint het conflict. De conflicterende winnaarwaarde van site A wordt doorgegeven aan sites B, C en D.

Fase 3: Meerdere wijzigingen in dezelfde rij

Stel dat site C de rij bijwerkt (en wijzigt naar North Carolina) en vervolgens synchroniseert met de uitgever. Dit is geen conflict omdat C de laatste update van A al succesvol heeft samengevoegd (met de rijwaarde ='Texas' succesvol is samengevoegd). Stel dat Site B de rij bijwerkt (en deze wijzigt naar Idaho).

Wanneer site B wordt gesynchroniseerd met de Publisher, is er een updateconflict. Omdat zowel B- als C serverabonnementen zijn en de prioriteit van B groter is dan die van C, wint site B het conflict. Nadat de andere twee sites ook zijn samengevoegd, wordt de waarde van B doorgegeven aan de andere abonnees.

Fase 4: Abonnees met server- en clientabonnementen werken beide de rij bij

Stel dat site D de rij bijwerkt (wijzigt in New Mexico) en synchroniseert met de uitgever. Stel dat Site B de rij bijwerkt (en deze wijzigt in Californië).

Wanneer site B wordt gesynchroniseerd met de Publisher, is er een updateconflict. In tegenstelling tot het vorige voorbeeld, omdat D een clientabonnement heeft, wordt ervan uitgegaan dat de prioriteitswaarde van publisher (site A) bij synchronisatie wordt gebruikt. Omdat de prioriteit van A groter is dan B, verliest B het conflict; de waarde die in eerste instantie in D is ingevoerd, wint. (Had Abonnee B gesynchroniseerd met A voordat Abonnee D dat deed, zou site B het conflict hebben gewonnen.) Site D die het conflict wint, is afhankelijk van het feit dat publisher geen wijziging heeft aangebracht of een andere wijziging heeft ontvangen omdat de versie van de rij die op Site D is bijgewerkt voor het laatst is gesynchroniseerd. Als een abonnee met een serverabonnement of een andere abonnee met een clientabonnement eerst wordt gesynchroniseerd, wordt de regel met de hoogste prioriteit of 'eerste in bij de uitgever wint' gevolgd.)

De uiteindelijke waarden nadat alle sites zijn gesynchroniseerd, worden hier weergegeven.

Synchronisatievolgorde en prioriteitswaarde bepalen het resultaat van conflicten bij het combineren van server- en clientabonnementen op hetzelfde niveau in uw topologie. Deze laatste set updates laat zien waarom voorzichtigheid moet worden uitgeoefend. Hoewel de abonnee de laagste prioriteitswaarde van de drie abonnees had, won het het conflict omdat deze eerst werd gesynchroniseerd met de uitgever (uitgaande van de prioriteitswaarde van 100,00). Had site C (serverabonnement met een prioriteitswaarde van 50,00) in New Mexico ingevoerd in plaats van site D, site B (serverabonnement met een prioriteitswaarde van 75,00) zou het conflict hebben gewonnen en zou het resultaat Californië zijn geweest.

Verwante inhoud

• Hoe samenvoegreplicatie conflicten detecteert en oplost