I've finally figured out how to reproduce this -- The problem is related to the log purging done by access log. Here is what I did:

Make changes to the database, that were replicated. Everything is happy.

Shut down slapd, modify the logpurge parameter so that log purging is done.

Restart slapd

Verified that log purging was done, and that everything was still happily in sync.

Stop slapd, restart slapd

Now the access log DB has generated a new CSN that is in the future of the suffix stored CSN.

So it appears that somehow the logpurge operation either causes a new contextCSN to be written at the time the server is shut down, or it erases the contextCSN held by the accesslog db.

Now, this is when I restarted slapd:

Nov 6 16:27:14 ldap-dev0 slapd[27400]: @(#) $OpenLDAP: slapd 2.3.28 (Oct 26 2006 13:41:27) $ ^Iquanah@ldap-uat00.stanford.edu:/usr/local/build/openldap-2.3.28/servers/slapd

However, the contextCSN that was generated is:

contextCSN: 20061107002625Z#000000#00#000000

This matches the time at which I started slapd when log purging was run:

Nov 6 16:26:25 ldap-dev0 slapd[27385]: @(#) $OpenLDAP: slapd 2.3.28 (Oct 26 2006 13:41:27) $ ^Iquanah@ldap-uat00.stanford.edu:/usr/local/build/openldap-2.3.28/servers/slapd

so I'd say that when log purge is run, it resets the contextCSN in the accesslog DB to the time at which slapd last started...

--Quanah

-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html