Så här identifierar och löser sammanslagningsreplikering konflikter

Med sammanslagningsreplikering kan flera noder göra autonoma dataändringar, så det finns situationer där en ändring som görs på en nod kan vara i konflikt med en ändring av samma data på en annan nod. I andra situationer stöter sammanslagningsagenten på ett fel, till exempel en begränsningsöverträdelse och kan inte sprida en ändring som görs på en viss nod till en annan nod. Den här artikeln beskriver typer av konflikter, hur konflikter identifieras och löses samt faktorer som påverkar identifiering och lösning.

Identifiera och lösa konflikter

Sammanslagningsagenten lineage identifierar konflikter med hjälp av kolumnen i systemtabellen MSmerge_contents . Om spårning på kolumnnivå är aktiverat för en artikel COLV1 används även kolumnen. Dessa kolumner innehåller metadata om när en rad eller kolumn infogas eller uppdateras, och om vilka noder i en kopplingsreplikeringstopologi som har gjort ändringar i raden eller kolumnen. Du kan använda den sp_showrowreplicainfo systemlagrade proceduren för att visa dessa metadata.

När sammanslagningsagenten räknar upp ändringar som ska tillämpas under synkroniseringen jämförs metadata för varje rad i Publisher och Subscriber. Sammanslagningsagenten använder dessa metadata för att avgöra om en rad eller kolumn har ändrats på mer än en nod i topologin, vilket indikerar en potentiell konflikt. När en konflikt har identifierats startar Sammanslagningsagenten den konfliktlösare som angetts för artikeln med en konflikt och använder lösaren för att fastställa konfliktvinnaren. Den vinnande raden tillämpas på Utgivare och Prenumerant och data från den förlorande raden skrivs till en konflikttabell.

Konflikter löses automatiskt och omedelbart av sammanslagningsagenten om du inte har valt interaktiv konfliktlösning för artikeln. Mer information finns i Microsoft Replication Interactive Conflict Resolver. Om du manuellt ändrar den vinnande raden för en konflikt med hjälp av konfliktvisningsprogrammet för sammanslagningsreplikering tillämpar sammanslagningsagenten den vinnande versionen av raden på den förlorande servern under nästa synkronisering.

Logga lösta konflikter

När sammanslagningsagenten har löst konflikten enligt logiken i konfliktlösaren loggar den konfliktdata enligt typen av konflikt:

• För UPDATE och INSERT konflikter skriver den förlorande versionen av raden till konflikttabellen för artikeln, som heter i formatet conflict_<PublicationName>_<ArticleName>. Den allmänna konfliktinformationen, till exempel typen av konflikt, skrivs till tabellen MSmerge_conflicts_info.

• För DELETE konflikter skriver den den förlorande versionen av raden till tabellen MSmerge_conflicts_info. När en borttagning förloras mot en uppdatering finns det inga data för den förlorande raden (eftersom det var en borttagning), så ingenting skrivs till conflict_<PublicationName>_<ArticleName>.

Konflikttabellerna för varje artikel skapas i publikationsdatabasen, prenumerationsdatabasen eller båda (standardvärdet), beroende på det värde som anges för parametern @conflict_loggingsp_addmergepublicationför . Varje konflikttabell har samma struktur som den artikel som den baseras på, med tillägget av origin_datasource_id kolumnen. Sammanslagningsagenten tar bort data från konflikttabellen om den är äldre än konfliktens kvarhållningsperiod för publikationen, som anges med parametern @conflict_retentionsp_addmergepublication (standardvärdet är 14 dagar).

Replikering ger replikeringskonfliktsvisaren och lagrade procedurer (sp_helpmergearticleconflicts, sp_helpmergeconflictrows, och sp_helpmergedeleteconflictrows) för att visa konfliktdata. Mer information finns i Konfliktlösning för sammanslagningsreplikering.

Faktorer som påverkar konfliktlösning

Det finns två faktorer som påverkar hur sammanslagningsagenten löser en konflikt som den har identifierat:

• Typen av prenumeration: klient eller server (om prenumerationen är en pull-prenumeration eller en push-prenumeration påverkar inte konfliktlösningen).

• Typen av konfliktspårning som används: radnivå, kolumnnivå eller logisk postnivå.

Prenumerationstyper

När du skapar en prenumeration, förutom att ange om det är en push- eller pull-prenumeration, anger du om det är en klient- eller serverprenumeration. När en prenumeration har skapats kan inte typen ändras (i tidigare versioner av SQL Server kallades klient- respektive serverprenumerationer lokala respektive globala prenumerationer).

En prenumeration med ett tilldelat prioritetsvärde (från 0,00 till 99,99) kallas för en serverprenumeration. en prenumeration som använder prioritetsvärdet för Publisher kallas för en klientprenumeration. Dessutom kan prenumeranter med serverprenumerationer publicera om data till andra prenumeranter. I följande tabell sammanfattas de största skillnaderna och användningsområdena för varje prenumeranttyp.

Om en rad ändras i en klientprenumeration tilldelas ingen prioritet till ändringen förrän prenumerationen har synkroniserats. Under synkroniseringen tilldelas ändringarna från Prenumeranten prioriteten för Utgivaren och behåller den prioriteten för efterföljande synkroniseringar. På sätt och vis övertar utgivaren ägarskapet för ändringen. Det här gör att den första prenumeranten kan synkronisera med Utgivaren för att vinna efterföljande konflikter med andra prenumeranter för en viss rad eller kolumn.

När du ändrar en rad i en serverprenumeration lagras prenumerationsprioriteten i metadata för ändringen. Det här prioritetsvärdet överförs med den ändrade raden när den sammanfogas med ändringar hos andra prenumeranter. Detta säkerställer att en ändring som görs av en prenumeration med högre prioritet inte förlorar en efterföljande ändring som görs av en prenumeration med lägre prioritet.

En prenumeration kan inte ha ett explicit prioritetsvärde som är högre än dess Utgivare. Topnivåutgivaren i en topologi för sammanslagningsreplikering har alltid ett explicit prioritetsvärde på 100,00. Alla prenumerationer på den publikationen måste ha ett prioritetsvärde som är mindre än det här värdet. I en topologi för återpublicering:

• Om prenumeranten publicerar om data måste prenumerationen vara en serverprenumeration med ett prioritetsvärde som är mindre än utgivaren ovanför prenumeranten.

• Om prenumeranten inte publicerar om data (eftersom den befinner sig på lövnivån i ompubliceringsträdet) måste prenumerationen vara en klientprenumeration.

Mer information om serverprenumerationer och prioriteringar finns i Exempel på sammanslagning av konfliktlösning baserat på prenumerationstyp och tilldelade prioriteringar.

Meddelande om fördröjd konflikt

Fördröjda konfliktmeddelanden kan inträffa med serverprenumerationer som har olika konfliktprioriteringar. Tänk på följande scenario, där icke-motstridiga ändringar utbyts mellan utgivaren och en prenumerant med lägre prioritet som resulterar i motstridiga ändringar när en prenumerant med högre prioritet synkroniseras med utgivaren:

1. Utgivaren och en lågprioriterad prenumerant med namnet LowPrioritySub utbyter ändringar över flera synkroniseringar utan konflikt.

2. En prenumerant med högre prioritet med namnet HighPrioritySub har inte synkroniserats med Utgivaren på länge och har gjort ändringar i samma rader som LowPrioritySub-prenumeranten har gjort.

3. HighPrioritySub-prenumeranten synkroniseras med utgivaren och vinner konflikterna mellan dess ändringar och LowPrioritySub-prenumeranten eftersom den har en högre prioritet än LowPrioritySub-prenumeranten. Utgivaren har nu de ändringar som gjorts av HighPrioritySub prenumeranten.

4. LowPrioritySub-prenumeranten sammanfogas sedan med utgivaren och laddar ned ett stort antal ändringar på grund av konflikterna med HighPrioritySub-prenumeranten.

Den här situationen kan bli problematisk när prenumeranten med lägre prioritet har gjort ändringar i samma rader som nu är konfliktförlorare. Detta kan leda till att alla ändringar som görs av prenumeranten går förlorade. En möjlig lösning på det här problemet är att se till att alla prenumeranter har samma prioritet, såvida inte affärslogik dikterar något annat.

Spårningsnivå

Om en dataändring kvalificerar sig som en konflikt eller inte beror på vilken typ av konfliktspårning du har angett för en artikel: radnivå, kolumnnivå eller logisk postnivå. Mer information om spårning på logisk postnivå finns i Avancerad sammanslagningsreplikering - Konfliktlösning i logisk post.

När konflikter identifieras på radnivå bedöms ändringar som görs i motsvarande rader som en konflikt, oavsett om ändringarna görs i samma kolumn eller inte. Anta till exempel att en ändring görs i adresskolumnen på en Publisher-rad och att en andra ändring görs i kolumnen telefonnummer för motsvarande prenumerantrad (i samma tabell). Med spårning på radnivå identifieras en konflikt eftersom ändringar har gjorts i samma rad. Med spårning på kolumnnivå identifieras ingen konflikt eftersom ändringar har gjorts i olika kolumner på samma rad.

För spårning på radnivå och kolumnnivå är konfliktlösningen densamma: hela dataraden skrivs över av data från konfliktvinnaren (för logisk spårning på postnivå beror lösningen på artikelegenskapen logical_record_level_conflict_resolution).

Programsemantiken avgör vanligtvis vilket spårningsalternativ som ska användas. Om du till exempel uppdaterar kunddata som vanligtvis anges samtidigt, till exempel en adress och ett telefonnummer, bör spårning på radnivå väljas. Om spårning på kolumnnivå valdes i den här situationen skulle ändringar av kundadressen på en plats och kundens telefonnummer på en annan plats inte identifieras som en konflikt: data skulle sammanfogas vid synkronisering och felet skulle missas. I andra situationer kan det mest logiska valet vara att uppdatera enskilda kolumner från olika platser. Två webbplatser kan till exempel ha tillgång till olika typer av statistisk information om en kund, till exempel inkomstnivå och totalt antal kreditkortsköp i dollar. Om du väljer spårning på kolumnnivå ser du till att båda platserna kan ange statistiska data för olika kolumner utan att skapa onödiga konflikter.

Konflikttyper

Även om de flesta konflikter är relaterade till uppdateringar (en uppdatering på en nod står i konflikt med en uppdatering eller borttagning på en annan nod), finns det andra konflikttyper. Varje typ av konflikt som beskrivs i det här avsnittet kan inträffa under uppladdningsfasen eller nedladdningsfasen för sammanslagningsbearbetning. Uppladdningsbearbetning är den första avstämningen av ändringar som utförs i en viss sammanslagningssession och är den fas under vilken sammanslagningsagenten replikerar ändringar från Prenumeranten upp till utgivaren. Konflikter som identifieras under den här bearbetningen kallas för uppladdningskonflikter. Nedladdningsbearbetning innebär att ändringar flyttas från utgivaren till prenumeranten och sker efter uppladdningsbearbetningen. Konflikter under den här bearbetningsfasen kallas nedladdningskonflikter.

Mer information om konflikttyper finns i MSmerge_conflicts_info, särskilt kolumnerna conflict_type och reason_code .

Konflikter vid uppdatering av uppdateringar

Sammanslagningsagenten identifierar uppdateringsuppdateringskonflikter när en uppdatering av en rad (eller kolumn eller logisk post) på en nod står i konflikt med en annan uppdatering till samma rad på en annan nod. Beteendet för standardlösaren i det här fallet är att skicka den vinnande versionen av raden till den förlorande noden och logga den förlorande radversionen i artikelkonflikttabellen.

Konflikter vid uppdateringar och borttagningar

Sammanslagningsagenten identifierar konflikter vid uppdateringsborttagning när en uppdatering av data på en nod står i konflikt med en borttagning på en annan. I det här fallet uppdaterar sammanslagningsagenten en rad. Men när sammanslagningsagenten söker efter den raden på målet kan den inte hitta raden eftersom den har tagits bort. Om vinnaren är den nod som uppdaterade raden ignoreras borttagningen vid den förlorande noden och sammanslagningsagenten skickar den nyligen uppdaterade raden till konfliktförloraren. Sammanslagningsagenten loggar information om den förlorade versionen av raden till MSmerge_conflicts_info tabellen.

Misslyckade ändringskonflikter

Sammanslagningsagenten skapar dessa konflikter när den inte kan tillämpa en viss ändring. Detta beror vanligtvis på en skillnad i villkorsdefinitioner mellan utgivaren och prenumeranten och användningen av NOT FOR REPLICATION egenskapen (NFR) för villkoret. Exempel är:

• En främmande nyckelkonflikt hos abonnenten, vilket kan inträffa när begränsningen på abonnentsidan inte markeras som NFR.

• Skillnader i begränsningar mellan Utgivare och Prenumeranter och begränsningarna markeras inte som NFR.

• Otillgänglighet för beroende objekt hos prenumeranten. Om du till exempel publicerar en vy, men inte den tabell som vyn är beroende av, uppstår ett fel om du försöker infoga den vyn i Prenumeranten.

• Implementera filtreringslogik för en publikation som inte matchar begränsningarna för primärnyckel och extern nyckel. Konflikter kan uppstå när SQL Server-relationsmotorn försöker uppfylla en begränsning, men sammanslagningsagenten följer definitionen för kopplingsfilter mellan artiklarna. Sammanslagningsagenten kan inte tillämpa ändringen på målnoden på grund av begränsningarna på tabellnivå, vilket resulterar i en konflikt.

• Konflikter på grund av unika index- eller unika begränsningsöverträdelser eller primära nyckelöverträdelser kan inträffa om identitetskolumner definieras för artikeln och automatiserad identitetshantering inte används. Detta kan vara ett problem om två prenumeranter skulle använda samma identitetsvärde för en rad som nyligen infogats. Mer information om hantering av identitetsintervall finns i Replikera identitetskolumner.

• Konflikter på grund av utlösarlogik som hindrar Merge-agenten från att infoga en rad i måltabellen. Överväg en uppdateringsutlösare som har definierats i Prenumeranten; utlösaren är inte markerad som NFR och innehåller en ROLLBACK i sin logik. Om ett fel inträffar utfärdar utlösaren en ROLLBACK av transaktionen, vilket resulterar i att sammanslagningsagenten identifierar en misslyckad ändringskonflikt.

Relaterat innehåll

• Sammanslagen replikering
• MSmerge_conflicts_info (Transact-SQL)
• MSmerge_contents (Transact-SQL)
• sp_addmergepublication (Transact-SQL)
• sp_helpmergearticleconflicts (Transact-SQL)
• sp_helpmergeconflictrows (Transact-SQL)
• sp_helpmergedeleteconflictrows (Transact-SQL)
• Kontrollbeteende för utlösare och begränsningar i synkronisering
• Avancerad sammanslagningsreplikering – Konfliktidentifiering och lösning
• Återpublicera data