[Date Prev][Date Next]
Re: (ITS#5694) Usage of -w with slapadd breaks delta-syncrepl
--On Tuesday, September 09, 2008 12:19 PM -0700 Howard Chu <firstname.lastname@example.org>
> email@example.com wrote:
>> --On Tuesday, September 09, 2008 8:59 PM +0200 Pierangelo Masarati
>> <firstname.lastname@example.org> wrote:
>>>> I'll give what you suggested a try, but this is still a serious bug.
>>> There's something I don't clearly get. As far as I understand, you are
>>> saying that consumers lose sync when the log database is purged before
>>> they have a chance to sync (because they were down). I don't see how
>>> they could sync, then. Of course, there should be a means for
>>> slapo-syncprov(5) to tell that, and force a refresh.
>> Because the consumer is supposed to do a full refresh if they find their
>> context CSN doesn't match the contextCSN of the master.
> Not quite. More precisely, the provider is supposed to tell the consumer
> that the consumer's cookie is out of date if the cookie is older than
> anything in the provider, and the consumer asked for the reload Hint.
> Otherwise the provider just sees the consumer is stale and returns a full
> dump implicitly.
Well, the consumer's definitely not acting on a full dump in either case. :/
In my latest test, after the purge, I have:
on the master and
on the replica prior to starting it. SO the replica is clearly behind.
The new entry on the master is:
which matches the CSN on both the main DB and accesslog DB.
now, staring the replica, we find:
So, it believes it has sync'd now, but uid=qtest7 doesn't exist!
Principal Software Engineer
Zimbra :: the leader in open source messaging and collaboration