Re: syncrepl: contextCSN less than entryCSN

[Ioan Indreias <indreias@gmail.com>]

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