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

Re: CSN too old



I just remove the syncprov-checkpoint and also remove the interval=00:00:01:00

I have restarted the LDAP servers and try again, result is still the same.

Thanks

Oliver Liebel wrote:
i just took a look at your first mail in the thread, that i had not read
yet.
just two points:

  
syncprov-checkpoint 100 10
  
    
remove checkpoint
  
syncprov-sessionlog 100

# syncrepl directives
syncrepl      rid=002
             provider=ldap://10.166.23.218:389/
             bindmethod=simple
             binddn="cn=Manager"
             credentials=secret
             searchbase="o=HKSARG"
             schemachecking=off
             type=refreshAndPersist
             attrs="*,+"
             retry="1 +"
             interval=00:00:01:00
    
dont use refreshAndPersist AND interval=  together as the
second one is for refreshOnly Mode.




Paul Lee schrieb:
  
Hi Oliver,

I have checked by using the command ntpq -p <host1 host2>, and the
result is below :

[root@webserver openldap]# ntpq -p 10.0.1.34 202.245.193.128
ser      remote           refid      st t when poll reach   delay  
offset  jitter
==================================================================================
10.0.1.34 *202.245.193.128 LOCAL(0)        11 u  131 1024  377   
0.410    1.423   3.083
ser      remote           refid      st t when poll reach   delay  
offset  jitter
==================================================================================
202.245.193.128 *LOCAL(0)        LOCAL(0)        10 l   43   64 
377    0.000    0.000   0.004
[root@webserver openldap]# ntpq -p 10.0.1.34 202.245.193.128
ser      remote           refid      st t when poll reach   delay  
offset  jitter
==================================================================================
10.0.1.34 *202.245.193.128 LOCAL(0)        11 u  133 1024  377   
0.410    1.423   3.083
ser      remote           refid      st t when poll reach   delay  
offset  jitter
==================================================================================
202.245.193.128 *LOCAL(0)        LOCAL(0)        10 l   45   64 
377    0.000    0.000   0.004

The offset value seems small, but when I add records to 10.0.1.34 LDAP
server, the other LDAP server 202.245.193.128 can't see that records,
but found "CSN too old" in the ldap log.

Any suggestion to solve this problem ?  Is there any way to increase
the tolerance, or any other alternative way ?

Thanks


Oliver Liebel wrote:
    
Paul Lee schrieb:
      
Hi Oliver,

I have updated to version 2.4.11 and the problem still exists.  Do I
need to remove all data in other servers (leaving 1 as master) and
then let them synchronized from the master server ?
        
thats what i would try, but before you resync, check/sync the time
exactly on all nodes (see below).
      
I have checked the ntp is running and ntpq -p and check the jlitter
value is less than 10.
        
checked the offset on all correspondings nodes ? ntpq -p <host1 host2
...>
once again, timesync is very sensitive to mmr (as i said - very small
timeslices,
2.4 csns have additionally 6 digits for microseconds) .
there can be an offset to the (external) ntp, but the offset should
be the same an all nodes.
if youre using  virtual machines, they can cause lots of problems in
syncing time.

      
Thanks


Oliver Liebel wrote:

        
take a look at the changelogs. many reasons to upgrade,
especially syncrepl/syncrov and contextcsn -related bugfixes.

          
Is there any larger tolerance can be configured ?

Besides upgrade to 2.4.11, any other alternative method ?  It's
because we have gone through many testing in 2.4.9, if change to
2.4.11, need to re-test all again.

Thanks

            
absolutely sure?
timeslices needed for mmr in 2.4 are very small
so all servers have to be in exact sync.
maybe you should check/recalibrate and refill the dit again.


Paul Lee schrieb:

          
yes, all servers' clock are in sync...

Thanks


Oliver Liebel wrote:

            
time-sync ok?
and you should upgrade to 2.4.11.


Paul Lee schrieb:

              
Dear all,

I am using openldap version 2.4.9, I am using 4 ldap servers
with 4-way master configured.

Data can be synronized initially, but when the records is
getting more and more, now is around 100k records, I always find
data is not synronized between the four ldap servers.

I find that "CSN is too old, ignoring" in the LDAP log file.

Sep 24 04:04:03 disb01 slapd[28779]: do_syncrep2:
cookie=rid=003,sid=001,csn=20080923200403.713637Z#000000#003#000000
Sep 24 04:04:03 disb01 slapd[28779]: do_syncrep2: rid=003 CSN
too old, ignoring 20080923200403.713637Z#000000#003#000000
Sep 24 04:04:03 disb01 slapd[28779]: do_syncrep2:
cookie=rid=002,sid=001,csn=20080923200403.713637Z#000000#003#000000
Sep 24 04:04:03 disb01 slapd[28779]: do_syncrep2: rid=002 CSN
too old, ignoring 20080923200403.713637Z#000000#003#000000
Sep 24 04:04:03 disb01 slapd[28779]: do_syncrep2:
cookie=rid=002,sid=001,csn=20080923200403.739461Z#000000#002#000000
Sep 24 04:04:03 disb01 slapd[28779]: syncrepl_entry: rid=002
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)
Sep 24 04:04:03 disb01 slapd[28779]: syncrepl_entry: rid=002
be_search (0)
Sep 24 04:04:03 disb01 slapd[28779]: syncrepl_entry: rid=002
cn=pwdfail,ou=SCIG,ou=Govt-Dept,o=HKSARG

Any idea of this kind of error and how to fixed it ?

Thanks

Confidential Communication - This e-mail (including any
attachments) is confidential and may be legally privileged. If
this e-mail has been sent to you by mistake please inform us by
reply e-mail and then delete the e-mail, destroy any printed
copy and do not disclose or use the information in it.

                
____________
Virus checked by G DATA AntiVirusKit
Version: AVK 19.689 from 24.09.2008
Virus news: www.antiviruslab.com


              
Confidential Communication - This e-mail (including any
attachments) is confidential and may be legally privileged. If
this e-mail has been sent to you by mistake please inform us by
reply e-mail and then delete the e-mail, destroy any printed copy
and do not disclose or use the information in it.


            
____________
Virus checked by G DATA AntiVirusKit
Version: AVK 19.690 from 24.09.2008
Virus news: www.antiviruslab.com


          
Confidential Communication - This e-mail (including any attachments)
is confidential and may be legally privileged. If this e-mail has
been sent to you by mistake please inform us by reply e-mail and
then delete the e-mail, destroy any printed copy and do not disclose
or use the information in it.


        
____________
Virus checked by G DATA AntiVirusKit
Version: AVK 19.700 from 25.09.2008
Virus news: www.antiviruslab.com


      
Confidential Communication - This e-mail (including any attachments) is confidential and may be 
legally privileged. If this e-mail has been sent to you by mistake please inform us by reply 
e-mail and then delete the e-mail, destroy any printed copy and do not disclose or use the 
information in it.

    

  
Confidential Communication - This e-mail (including any attachments) is confidential and may be 
legally privileged. If this e-mail has been sent to you by mistake please inform us by reply 
e-mail and then delete the e-mail, destroy any printed copy and do not disclose or use the 
information in it.