> so it is tracking "000" as a third master? This seems to be why the > original server (which was 000 before being promoted to 001) replicates > these entries back to itself. The loop is caused by the patch to ITS#6872, which considers a consumer out of date whenever the number of CSNs in its sync request doesn't match the number known to the provider. The data here is basically invalid: server1 has entries generated using SID=0 but it has no contextCSN value with SID=0. It only sent SID=1 and SID=2 in its sync request. Server2, which just updated from server1, has a contextCSN for SID=0 in addition to 1 and 2 (and that's all correct). Server1 should have always had a contextCSN value for SID=0 but doesn't. This problem would not occur if server1 was converted first from standalone into a single-master. I.e., load syncprov on it, let it scan the DB and generate the first sid=0 contextCSN, before turning it intu a MMR node.