[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: syncrepl: contextCSN less than entryCSN
Hello Howard,
I understand your point but I am 100% sure that we were not in such a
situation (refresh phase) as the "problem" was there for more minutes
(sometimes more hours).
My personal feeling is that the contextCSN is not updated correctly
and this is why I was thinking it is a bug.
Do you know other reasons why an entryCSN from the LDAP could be
greater than the contextCSN?
Best regards,
Ioan
On Wed, Sep 15, 2010 at 12:36 PM, Howard Chu <hyc@symas.com> wrote:
> 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/
>