I think you're right about maxversion_at_cleanup being a symptom of a bigger problem. We dropped the smaller article and re-published it over the weekend and the maxversion_at_cleanup reset back to "1". Now when subscribers synchronize they don't seem to increment that value, even when there are changes to that article being replicated. If it does change, it seems to reset back to "1" since that's the only value we've seen since yesterday.

I've also changed the partition_options to "0" instead of "1" - it used to disallow out of partition changes. I don't know if that impacts how this value is handled.

I still don't understand what causes this value to change or in what scenarios it may climb exponentially. I don't believe our problem is hardware related at this point, CPU, Disk IO, etc. would all be symptoms of what I think is really wrong - a configuration problem with replication.

Our replication system has been running for years without this problem occurring, so I suppose it's possible we've encountered some state with some of our articles that requires them to be dropped and re-added in order to clean it up.

Thank you for your thoughts, and if anyone has any insights into how we've got into the situation of a really high maxversion_at_cleanup, or how it can be cleaned up without dropping/re-adding please let me know. Otherwise we may look to schedule a complete reset of the publication on a closed holiday.