[Date Prev][Date Next]
Re: (ITS#7274) delta-syncrepl MMR infinite loop
--On Tuesday, May 29, 2012 6:25 PM -0700 Howard Chu <email@example.com>
>> 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.
Sr. Member of Technical Staff
A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration