--On Tuesday, May 29, 2012 6:25 PM -0700 Howard Chu <hyc(a)openldap.org>
> 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
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.
Sr. Member of Technical Staff
A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration