--On Tuesday, May 29, 2012 6:25 PM -0700 Howard Chu <[email protected]> wrote:
>> 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. For documentation purposes -- The issue occurred because I set olcServerID before I loaded syncprov. Re-ordering my script to load syncprov (which then caused a contextCSN value to be correctly generated on Server1 for SID=0) fixed this loop. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
