Hi Oliver,
I got the following result when using ntpq -p
PISB01
Remote
refid st t when
poll reach delay offset
jitter
LOCAL(0)
LOCAL(0) 10 1 44
64 377 0.000 0.000
0.001
172.106.3.3
10.106.241.81 5 u 187 1024
377 0.820 -0.243 0.002
PISB02
Remote
refid st t when
poll reach delay offset
jitter
LOCAL(0)
LOCAL(0) 10 1 15
64 377 0.000 0.000
0.001
172.106.3.3
10.106.241.81 5 u 704 1024
377 1.416 -0.952 7.755
Is it the jlitter
and offset too high for the records out of sync ?
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. |
|