On 14/09/2010 12:30, Ioan Indreias wrote:
Hello,
We are running openldap 2.4.21 configured as a consumer, using a refreshAndPersist replication:
syncrepl rid=202 provider=ldaps://ldap.hashed.net type=refreshAndPersist interval=00:00:05:00 retry="10 3 60 +" searchbase="ou=emailservice,o=hashed" filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off bindmethod=simple binddn="cn=ldap-hashed-service,o=hashed" credentials=xx-xx-xx tls_reqcert=never
In order to check if the replication works OK we compare (periodically) the provider's contextCSN versus the consumer's contextCSN
Most of the time both are in sync but from time to time we see that these parameters are different (provider contextCSN> consumer contextCSN) and we thought that the consumer was not "in sync" with the provider.
Continuing our investigations we found that in the consumer there are objects with entryCSN greater than the consumer contextCSN.
Is this a normal situation or a bug?
What method do you use to consult the contextCSN?
As stated in slapo-syncrepl(5), "the contextCSN is only updated in memory". So if you're using slapcat to check the value, this is pretty normal. See the slapo-checkpoint option to control the frequency it is written to disk.
If you're checking via LDAP, then this is a whole different matter...