Error Message:
The merge process failed because it detected a mismatch between the replication metadata of the two replicas, such that some changes could be lost leading to non-convergence. This could be due to the subscriber not having synchronized within the retention period, or because of one of the replicas being restored to a backup older than retention period, or because of the publisher performing more aggressive cleanup on articles of type download-only and articles with partition_options = 3. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147199363)
Get help: http://help/MSSQL_REPL-2147199363
The common generation watermark is invalid at this replica since it does not exist or metadata for changes not yet propagated may have been cleaned up. (Source: MSSQLServer, Error number: 21800)
Get help: http://help/21800
———————–
Let us see how replication works: a subscriber connects to the publisher, submitting its knowledge about which generations have already been sent and received. If the generations sent and received do not match, then the replication will fails by saying non-convergence can happen.
If you look in the table, sysmergesubscriptions, you will see four columns: sentgen, sentguid, recgen, and recguid. These are the columns that tell the last generations synchronized. Depending on whether you are looking at the publisher or subscriber will determine what the columns actually mean as far as direction. If you are looking at the publisher, then sentgen and sentguid refer to the last generation sent to the subscriber. If you are looking at the subscriber, then sentgen and sentguid refer to the last generation sent to the publisher. If you get the above error message, then it may be that the values do not match between the publisher and subscriber.
We have to trust either publisher or subscriber for accuracy, So let’s say that we trust the publisher to be accurate on the sentgen and recgen. All you need to do is copy the values for sentgen and sentguid into the recgen and recguid columns respectively, and the recgen and recguid into the sentgen and sentguid columns respectively at the subscriber. Your update statement will look something like:
UPDATE sysmergesubscriptions SET sentgen = 8664, sentguid = ‘DD172177-E223-417C-8BFF-9F72561280EA ‘, recgen = 13842769, recguid = 193C40B5-7A23-4A7A-B97E-885EC2A1FFD3′ where subid = pubid and pubid = F6646824-BCCC-443C-875B-0D700F63D075′
In the update statement we have “where subid = pubid.” That’s because there are two records for every publication at the subscriber, and only the one where the subid equals the pubid is used to track generations.
If synchronization is being taken care by RMO programming then you can also take care of this issue in RMO programming as well.
Popularity: 14% [?]
Leave a Reply