Re: CSN too old

syncprov-checkpoint 100 10

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

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.