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 <[email protected]> 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<[email protected]> 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 >>> <[email protected]> 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 - [email protected] >>>> -------------------------------------------------------------- >>>> 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/ >
