i just took a look at your first mail in the thread, that i had not read
yet.
just two points:
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.