--On Tuesday, September 09, 2008 12:19 PM -0700 Howard Chu hyc@symas.com wrote:
quanah@zimbra.com wrote:
--On Tuesday, September 09, 2008 8:59 PM +0200 Pierangelo Masarati ando@sys-net.it 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:
# accesslog dn: cn=accesslog
contextCSN: 20080909190440.484524Z#000000#000#000000
dn: contextCSN: 20080909190440.484524Z#000000#000#000000
on the master and
contextCSN: 20080909183254.258851Z#000000#000#000000
on the replica prior to starting it. SO the replica is clearly behind. The new entry on the master is:
dn: uid=qtest7,cn=admins,cn=zimbra entryCSN: 20080909190440.484524Z#000000#000#000000
which matches the CSN on both the main DB and accesslog DB.
now, staring the replica, we find:
contextCSN: 20080909190440.484524Z#000000#000#000000
So, it believes it has sync'd now, but uid=qtest7 doesn't exist!
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration