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.
________________________________
From: openldap-technical-bounces+chris.carr=camden.gov.uk@OpenLDAP.org [mailto:openldap-technical-bounces+chris.carr=camden.gov.uk@OpenLDAP.org ] On Behalf Of Paul Lee Sent: 24 September 2008 09:40 To: openldap-technical@openldap.org Subject: CSN too old 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.
Personally I'm still quite a fan of CSN - I don't think they're too old at all.
CC
This e-mail may contain information which is confidential, legally privileged and/or copyright protected. This e-mail is intended for the addressee only. If you receive this in error, please contact the sender and delete the material from your computer
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
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.
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
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 ?
I have checked the ntp is running and ntpq -p and check the jlitter value is less than 10.
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.
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
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.
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.
On Fri, 26 Sep 2008 10:34:04 +0200 Oliver Liebel oliver@itc.li 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
why does he need to remove the checkpoint?
Pavlos Parissis schrieb:
On Fri, 26 Sep 2008 10:34:04 +0200 Oliver Liebel oliver@itc.li 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
why does he need to remove the checkpoint?
it could cause trouble with csn-updates in mmr-setups with some 2.4 versions, see: http://www.openldap.org/lists/openldap-technical/200803/msg00062.html
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.
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.
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
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.
openldap-technical@openldap.org
-
Carr, Chris -
Oliver Liebel -
Paul Lee -
Pavlos Parissis