[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: syncrepl: contextCSN less than entryCSN

Ioan Indreias wrote:

well - I understand that nobody meet such a case, with entryCSN grater
than the contextCSN.
There are plenty of situations where an entryCSN will be greater than the contextCSN. The most obvious is during a refresh phase, since entries are not sent in any particular order. In that case, the contextCSN is not updated until the refresh is completed. The fact that you see this occurring does not indicate that there is any bug or problem. 

we are planning to compile and test the latest stable version, hoping
that included syncrepl fixes will solve our problem.

Best regards,
Ioan


On Tue, Sep 14, 2010 at 4:35 PM, Ioan Indreias<indreias@gmail.com>  wrote:

Hello Jonathan,

For obtaining the contextCSN we are using ldapsearch like:

ldapsearch -H ... -x -D ... -b o=hashed -y pass_file -s base
'(contextCSN=*)' contextCSN

For the extract I have added to my original post we have used ldapsearch like:

ldapsearch -H ... -x -D ... -b o=hashed -y pass_file +

So I conclude we are using the in-memory information.

Best regards,
Ioan

On Tue, Sep 14, 2010 at 3:11 PM, Jonathan Clarke
<jonathan@phillipoux.net>  wrote:

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...

--
--------------------------------------------------------------
Jonathan Clarke - jonathan@phillipoux.net
--------------------------------------------------------------
Ldap Synchronization Connector (LSC) - http://lsc-project.org
--------------------------------------------------------------








--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/