Periodically we get server and local replicas out of sync. When a database owner discovers that different replicas have different document counts, the solution to put replicas back in sync is simple: clear replication history and cutoff date. The problem is when a user edits a document with critical data, the change doesn’t replicate across all replicas, and users of the database do things or make stuff based on what turns out to be incorrect data. One of our databases has, in simple terms, recipes for mixing highly explosive chemicals in hig pressure containers. Incorrect data could cause death. Is there a solution for better managing problems with replication cutoff dates, differing document counts, and/or replication syncronization?
Subject: RE: replication cutoff date
It sounds like you’re talking about a scenario where someone creates an update on a local replica and then fails to replicate that database for so long that it expires off the replication cutoff, and when they do replicate it doesn’t go out. I hate to think how many updates they’re not receiving during all that time. Isn’t it just as serious a problem that they have lots of out-of-date information locally, of documents that they did not edit?
Simple answer is, if it’s so critical that information be up to date, don’t let people use local replicas. Design the application in such a way that it must be used on the server; that way you can control all replication. Or, have the local replica check a timestamp that would let it detect that replication has not happened recently in a local replica (I’ve described how to do that elsewhere in this forum). If the database is not sufficiently up to date, refuse to let the user open it. That would force them to keep it up to date.
If you are already faced with the situation you’re talking about, and you want to make sure that all documents are equal in all server replicas, you could create your own consistency checker fairly easily. Create a server agent that opens a view in two replicas of the same database. The views should be sorted ascending by date modified, and then by document UNID or some other unique unchanging key.
Scan down the views in parallel and see whether they match – if not, “touch” the more recent version to force it to replicate out again to all the servers. Scan until you are finding documents in both replicas that are more recently modified than the replication cutoff. And there you go!