Replication: Fake Conflicts?

One problem that is hard to resolve / understand is fake conflicts within a merge replication topology.

 

Looking at a scenario in which fake conflicts were occurring, we saw that following:

 

Our affected subscriber is synchronizing with 2 publications that have retention=14. The publisher also has an additional publication with retention=30. All the publications are on the same published database.

 

For the affected rowguids, we noticed that the MSmerge_contents entry still exists on the publisher, but was recently cleaned up on the subscriber.

 

Example of what we saw:

 

For a column-tracking article:

                                                             

- common colv1 before cleanup shows that columns 1, 2, 3 had been updated previously

- clean-up removes the MSmerge_contents row on sub but not on pub

- sub updates the row, thus inserting a new row into MSmerge_contents

- updated columns are 2 and 3

- synchronisation detects a mismatch, deduces a conflict, and the subscriber loses its data.

 

Reason for this issue in this scenario is:

 

The subscriber cleanup takes the 14 days limit, whereas the publisher clean-up uses the 30 day limit.

 

https://msdn.microsoft.com/en-us/library/ms151778.aspx

 

The default retention period for publications is 14 days. If an article belongs to several publications, there might be different retention periods. In that situation, the longest retention period is used to determine the earliest possible time that clean-up can occur.

 

Resolution in this case was to have all the publications set with the same retention period