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

Re: CSN too old

To: Paul Lee <paul@hk.fujitsu.com>
Subject: Re: CSN too old
From: Oliver Liebel <oliver@itc.li>
Date: Fri, 26 Sep 2008 10:34:04 +0200
Cc: openldap-technical@openldap.org
In-reply-to: <48DC3CDE.9020300@hk.fujitsu.com>
References: <48D9FCC3.2080903@hk.fujitsu.com> <48DA0528.8040606@itc.li> <48DA0701.9060501@hk.fujitsu.com> <48DA3119.3090008@itc.li> <48DB507A.604@hk.fujitsu.com> <48DB780F.9020308@itc.li> <48DC3CDE.9020300@hk.fujitsu.com>
User-agent: Thunderbird 2.0.0.16 (X11/20080720)

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

Follow-Ups:
- Re: CSN too old
  - From: Pavlos Parissis <p_pavlos@freemail.gr>
- Re: CSN too old
  - From: Paul Lee <paul@hk.fujitsu.com>

References:
- CSN too old
  - From: Paul Lee <paul@hk.fujitsu.com>
- Re: CSN too old
  - From: Oliver Liebel <oliver@itc.li>
- Re: CSN too old
  - From: Paul Lee <paul@hk.fujitsu.com>
- Re: CSN too old
  - From: Oliver Liebel <oliver@itc.li>
- Re: CSN too old
  - From: Paul Lee <paul@hk.fujitsu.com>
- Re: CSN too old
  - From: Oliver Liebel <oliver@itc.li>
- Re: CSN too old
  - From: Paul Lee <paul@hk.fujitsu.com>

Prev by Date: Re: CSN too old
Next by Date: Re: CSN too old
Index(es):
- Chronological
- Thread