3:01 a.m.
hi all,
sometimes my server a not in sync. because server ignoring entry:
do_syncrep2: rid=102 CSN too old, ignoring
20130923090023.266239Z#000000#002#000000
@(#) $OpenLDAP: slapd 2.4.33 (....)
4 server
host1 and host 2: only one database c=fr ( contain an ou=apps-ext )
host3 and host 4: tow database:
first ou=apps-ext (glued with c=fr ). writable by host1,2,3,4
second c=fr writable only by host1,2
ldap-int1 and ldap-int2 cn=config also into syncrepl mirrorMode
ldap-ext1 and ldap-ext2 cn=config also into syncrepl mirrorMode
Configuration:
grep serverID /etc/openldap/slapd.d/*
/etc/openldap/slapd.d/cn=config.ldif:olcServerID: 1 ldaps://ldap-int1.dom.fr
/etc/openldap/slapd.d/cn=config.ldif:olcServerID: 2 ldaps://ldap-int2.dom.fr
/etc/openldap/slapd.d/cn=config.ldif:olcServerID: 3 ldaps://
ldap-ext1.vlandata.dom.fr
/etc/openldap/slapd.d/cn=config.ldif:olcServerID: 4 ldaps://
ldap-ext2.vlandata.dom.fr
syncrepl:
ldap-int1 and ldap-int2 cn=config also into syncrepl
olcSyncrepl: {0}rid=101 provider=ldaps://ldap-int1.dom.frbinddn="uid=syncrepl
,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXXXXX sea
rchbase="c=fr" tls_reqcert=never type=refreshAndPersist
interval=00:00:00:10
retry="5 5 300 +" timeout=1
olcSyncrepl: {1}rid=102 provider=ldaps://ldap-int2.cdoms.frbinddn="uid=syncrepl
,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXXXXX sea
rchbase="c=fr" tls_reqcert=never type=refreshAndPersist
interval=00:00:00:10
retry="5 5 300 +" timeout=1
olcSyncrepl: {2}rid=103 provider=ldaps://ldap-ext2.vlandata.dom.frbinddn="uid
=syncrepl,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple
credentials=XX
XXXX tls_reqcert=never searchbase="o=apps-ext,c=fr" type=refreshAndPersist
r
etry="5 5 300 +" timeout=1
olcSyncrepl: {3}rid=104 provider=ldaps://ldap-ext1.vlandata.dom.frbinddn="uid
=syncrepl,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple
credentials=XXX
XXXX searchbase="o=apps-ext,c=fr" tls_reqcert=never type=refreshAndPersist
r
etry="5 5 300 +" timeout=1
syncrepl host3 and host4:
database apps-ext:
olcSyncrepl: {0}rid=303 provider=ldaps://ldap-ext1.vlandata.dom.frbinddn="uid
=syncrepl,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple
credentials=XXX
XXXX searchbase="o=apps-ext,c=fr" tls_reqcert=never type=refreshAndPersist
r
etry="5 5 300 +" timeout=1
olcSyncrepl: {1}rid=304 provider=ldaps://ldap-ext2.vlandata.dom.frbinddn="uid
=syncrepl,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple
credentials=XXX
XXX searchbase="o=apps-ext,c=fr" tls_reqcert=never type=refreshAndPersist r
etry="5 5 300 +" timeout=1
database c=fr:
olcSyncrepl: {0}rid=201 provider=ldaps://ldap-int1.dom.frbinddn="uid=syncrepl
,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXXXXX sea
rchbase="c=fr" tls_reqcert=never type=refreshOnly interval=00:00:00:10
retry=
"5 5 300 +" timeout=1
olcSyncrepl: {1}rid=202 provider=ldaps://ldap-int2.dom.frbinddn="uid=syncrepl
,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXXXX tls
_reqcert=never searchbase="c=fr" type=refreshOnly interval=00:00:00:10
retry=
"5 5 300 +" timeout=1
log message into ldap-int1:
ep 23 09:00:26 ldap-int1 slapd[30481]: do_syncrep2: rid=104
LDAP_RES_INTERMEDIATE - NEW_COOKIE
Sep 23 09:00:26 ldap-int1 slapd[30481]: do_syncrep2: rid=104 NEW_COOKIE:
rid=104,sid=003,csn=20130304121522.188962Z#000000#000#000000;20130920094938.821063Z#000000#001#000000;20130923081114.470856Z#000000#002#000000;20130920094950.036431Z#000000#003#000000;20130912174047.679980Z#000000#004#000000;20130304131428.455916Z#000000#00b#000000;20130304125618.164164Z#000000#00c#000000
Sep 23 09:00:26 ldap-int1 slapd[30481]: do_syncrep2: rid=104
LDAP_RES_INTERMEDIATE - NEW_COOKIE
Sep 23 09:00:26 ldap-int1 slapd[30481]: do_syncrep2: rid=104 NEW_COOKIE:
rid=104,sid=003,csn=20130304121522.188962Z#000000#000#000000;20130920094938.821063Z#000000#001#000000;20130923090023.733719Z#000000#002#000000;20130920094950.036431Z#000000#003#000000;20130912174047.679980Z#000000#004#000000;20130304131428.455916Z#000000#00b#000000;20130304125618.164164Z#000000#00c#000000
Sep 23 09:00:26 ldap-int1 slapd[30481]: slap_queue_csn: queing
0x7f3787471a90 20130923090023.733719Z#000000#002#000000
Sep 23 09:00:26 ldap-int1 slapd[30481]: slap_graduate_commit_csn: removing
0x7f37873baa10 20130923090023.733719Z#000000#002#000000
Sep 23 09:00:27 ldap-int1 slapd[30481]: syncprov_matchops: skipping
original sid 002
Sep 23 09:00:27 ldap-int1 slapd[30481]: slap_graduate_commit_csn: removing
0x7f37803e9320 20130923090023.225026Z#000000#002#000000
Sep 23 09:00:27 ldap-int1 slapd[30481]: syncrepl_entry: rid=102 be_add
cn=502257-dt-global-gridded-adt-ref,ou=affectations,ou=console,o=apps,c=fr
(0)
Sep 23 09:00:27 ldap-int1 slapd[30481]: do_syncrep2: rid=102
cookie=rid=102,sid=002,csn=20130923090023.266239Z#000000#002#000000
Sep 23 09:00:27 ldap-int1 slapd[30481]: do_syncrep2: rid=102 CSN too old,
ignoring 20130923090023.266239Z#000000#002#000000
(cn=502257-dt-med-gridded-sla-ref,ou=affectations,ou=console,o=apps,c=fr)
Sep 23 09:00:27 ldap-int1 slapd[30481]: do_syncrep2: rid=102
cookie=rid=102,sid=002,csn=20130923090023.278474Z#000000#002#000000
Sep 23 09:00:27 ldap-int1 slapd[30481]: do_syncrep2: rid=102 CSN too old,
ignoring 20130923090023.278474Z#000000#002#000000
(cn=502257-dt-blacksea-alongtrack-sla-ref,ou=affectations,ou=console,o=apps,c=fr)
time sync
host1
ntpq> lpeers
remote refid st t when poll reach delay offset
jitter
==============================================================================
*date.dom.fr 145.238.203.10 3 u 676 1024 377 1.592 0.284
0.018
+date2.dom.fr 145.238.203.10 3 u 295 1024 377 2.681 -0.410
0.326
host2
ntpq> lpeers
remote refid st t when poll reach delay offset
jitter
==============================================================================
*date.dom.fr 145.238.203.10 3 u 954 1024 377 1.028 1.012
0.343
+date2.dom.fr 145.238.203.10 3 u 413 1024 377 2.171 0.098
0.606
does somebody see what is wrong .
thanks
4 a.m.
On 09/24/2013 12:01 PM, Lanfeust troy wrote:
hi all,
sometimes my server a not in sync. because server ignoring entry:
do_syncrep2: rid=102 CSN too old, ignoring
20130923090023.266239Z#000000#002#000000
@(#) $OpenLDAP: slapd 2.4.33 (....)
If you search the list for any older version you will see a consistent
recommendation to upgrade to the latest version (currently 2.4.36) and
see if the problem persists.
If you use RHEL/CentOS you can find packages here:
http://ltb-project.org/wiki/download#openldap
Regards,
Patrick
6:15 a.m.
I understand that but before post my message i read openldap release note
but i can't see something related to my problem.
2013/9/24 Patrick Lists <openldap-list(a)puzzled.xs4all.nl>
On 09/24/2013 12:01 PM, Lanfeust troy wrote:
> hi all,
>
> sometimes my server a not in sync. because server ignoring entry:
>
> do_syncrep2: rid=102 CSN too old, ignoring
> 20130923090023.266239Z#000000#**002#000000
>
> @(#) $OpenLDAP: slapd 2.4.33 (....)
>
If you search the list for any older version you will see a consistent
recommendation to upgrade to the latest version (currently 2.4.36) and see
if the problem persists.
If you use RHEL/CentOS you can find packages here:
http://ltb-project.org/wiki/**download#openldap<http://ltb-project.org...
Regards,
Patrick
8:14 a.m.
On Tue, 24 Sep 2013, Lanfeust troy wrote:
I understand that but before post my message i read openldap release
note but i can't see something related to my problem.
[which is]
do_syncrep2: rid=102 CSN too old, ignoring
20130923090023.266239Z#000000#002#000000
@(#) $OpenLDAP: slapd 2.4.33 (....)
So you're running MMR and seeing issues about "old" CSNs and don't see
the
potential relevance of a change log that references:
Fixed slapd syncrepl updateCookie status (ITS#7531)
Fixed slapd syncrepl for old entries in MMR setup (ITS#7427)
...maybe they're your issue, maybe they're not, but in the amount of time
you need to simply read this you could find a 2.4.36 package.
2:05 a.m.
Hi all,
I have upgraded to 2.4.36 openLDAP version. The problem still exists.
It seem to be appear less than before. This week this problem occur only
once.
To resolve this problem i'm doing:
stop slapd on ldap that haven't entry
and launch it with
/usr/local/openldap/libexec/slapd -c
rid=201,dsn=20131003140020.844217Z#000000#002#000000 -h "ldap://:389
ldaps://:636" -F /usr/local/openldap/etc/openldap/slapd.d -u ldap -g ldap
-l local4
rid number is my source syncrepl
dsn is 20 seconds before the problem ( retrieve from entryCSN in question )
is't the good way to do
2013/9/24 Aaron Richton <richton(a)nbcs.rutgers.edu>
On Tue, 24 Sep 2013, Lanfeust troy wrote:
I understand that but before post my message i read openldap release note
> but i can't see something related to my problem.
>
[which is]
do_syncrep2: rid=102 CSN too old, ignoring
> 20130923090023.266239Z#000000#**002#000000
>
> @(#) $OpenLDAP: slapd 2.4.33 (....)
>
So you're running MMR and seeing issues about "old" CSNs and don't see
the
potential relevance of a change log that references:
Fixed slapd syncrepl updateCookie status (ITS#7531)
Fixed slapd syncrepl for old entries in MMR setup (ITS#7427)
...maybe they're your issue, maybe they're not, but in the amount of time
you need to simply read this you could find a 2.4.36 package.
3:31 a.m.
On Fri, 4 Oct 2013 11:05:57 +0200 Lanfeust troy <lanfeust99(a)gmail.com> wrote
I have upgraded to 2.4.36 openLDAP version. The problem still exists.
It seem to be appear less than before. This week this problem occur only
once.
I did not follow your issue in detail.
Are you using slapo-memberof in your deployment?
Ciao, Michael.
5:43 a.m.
No; it's not the problem
2013/10/4 Michael Ströder <michael(a)stroeder.com>
On Fri, 4 Oct 2013 11:05:57 +0200 Lanfeust troy
<lanfeust99(a)gmail.com>
wrote
>
> I have upgraded to 2.4.36 openLDAP version. The problem still exists.
> It seem to be appear less than before. This week this problem occur only
> once.
I did not follow your issue in detail.
Are you using slapo-memberof in your deployment?
Ciao, Michael.
1:13 a.m.
another logs with 2.4.36
ldap-int1 receive syncrepl modification from ldap-int2 with this log:
ldap-int1 log:
syncprov_matchops: skipping original sid 002
Oct 4 15:00:24 ldap-int1 slapd[24555]: slap_graduate_commit_csn: removing
0x7f7bf8200b40 20131004150021.988007Z#000000#002#000000
Oct 4 15:00:24 ldap-int1 slapd[24555]: syncrepl_entry: rid=102 be_add
cn=502296-xxxxxx,ou=aaaaa,ou=bbbb,o=cccc,c=dd (0)
... ...
ldap-ext2 receive the same modification an reply to ldap-int1 with new
cookie
ldap-int1 log
Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=103 NEW_COOKIE:
rid=103,sid=004,csn=20130304121522.188962Z#000000#000#000000;20131004082718.688747Z#000000#001#000000;20131004150023.350876Z#000000#002#000000;20130920094950.036431Z#000000#003#000000;20130930134451.718477Z#000000#004#000000;20130304131428.455916Z#000000#00b#000000;20130304125618.164164Z#000000#00c#00000
Another modification from ldap-int2 isn't apply to ldap-int1 because of csn
too old
Oct 4 15:00:24 ldap-int1 slapd[24555]: syncrepl_entry: rid=102 be_add
cn=502296-bbbb,ou=aaaaa,ou=bbbb,o=cccc,c=dd (0)
Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=102
cookie=rid=102,sid=002,csn=20131004150022.050845Z#000000#002#000000
Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=102 CSN too old,
ignoring 20131004150022.050845Z#000000#002#000000
(cn=502296-bbbb,ou=aaaaa,ou=bbbb,o=cccc,c=dd)
Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=102
cookie=rid=102,sid=002,csn=20131004150022.100121Z#000000#002#000000
2013/10/4 Lanfeust troy <lanfeust99(a)gmail.com>
No; it's not the problem
2013/10/4 Michael Ströder <michael(a)stroeder.com>
> On Fri, 4 Oct 2013 11:05:57 +0200 Lanfeust troy <lanfeust99(a)gmail.com>
> wrote
> >
> > I have upgraded to 2.4.36 openLDAP version. The problem still exists.
> > It seem to be appear less than before. This week this problem occur only
> > once.
>
> I did not follow your issue in detail.
> Are you using slapo-memberof in your deployment?
>
> Ciao, Michael.
>
>
>
3:15 a.m.
New subject: Antw: Re: another CSN too old N-WAY master
Hi!
Are you sure you are chasing a real problem? AFAIK, in multi-master sync, the
server that receives a change will send that change to all other nodes, which,
in turn, will also send the changes received to all other nodes. That means
that the original submitter of the changes will receive ist own change.
I also think that "too old" means "not newer" here. I wonder if the
message
shouldn't be dropped instead of complaining that the requested change is
already there.
The gurus may correct me if I'm wrong.
Regards,
Ulrich
688747Z#000000#001#000000;20131004150023.350876Z#000000#002#000000;2013092009
4950.036431Z#000000#003#000000;20130930134451.718477Z#000000#004#000000;20130
> 304131428.455916Z#000000#00b#000000;20130304125618.164164Z#000000#00c#00000
>
> Another modification from ldap-int2 isn't apply to ldap-int1 because of csn
> too old
>
> Oct 4 15:00:24 ldap-int1 slapd[24555]: syncrepl_entry: rid=102 be_add
> cn=502296-bbbb,ou=aaaaa,ou=bbbb,o=cccc,c=dd (0)
> Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=102
> cookie=rid=102,sid=002,csn=20131004150022.050845Z#000000#002#000000
> Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=102 CSN too old,
> ignoring 20131004150022.050845Z#000000#002#000000
> (cn=502296-bbbb,ou=aaaaa,ou=bbbb,o=cccc,c=dd)
> Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=102
> cookie=rid=102,sid=002,csn=20131004150022.100121Z#000000#002#000000
>
>
>
>
>
> 2013/10/4 Lanfeust troy <lanfeust99(a)gmail.com >
>> No; it's not the problem
> > >> 2013/10/4 Michael Ströder
<michael(a)stroeder.com >
>>> On Fri, 4 Oct 2013 11:05:57 +0200 Lanfeust troy
<lanfeust99(a)gmail.com >>> wrote
>>> >>> > I have upgraded to
2.4.36 openLDAP version. The problem still exists.
>>> > It seem to be appear less than before. This week this problem occur
only
>>> > once.
>> >>> I did not follow your
issue in detail.
>>> Are you using slapo-memberof in your deployment?
>> >>> Ciao, Michael.
>> >> >> >
>> Lanfeust troy <lanfeust99(a)gmail.com> schrieb am
08.10.2013 um 10:13 in
Nachricht
<CAJ=nZHMkk9hd7UdcrDW6zirjheBXqcjkhHBFEbvP3nTJu+v9Fg(a)mail.gmail.com>:
another logs with 2.4.36
ldap-int1 receive syncrepl modification from ldap-int2 with this log:
ldap-int1 log:
syncprov_matchops: skipping original sid 002
Oct 4 15:00:24 ldap-int1 slapd[24555]: slap_graduate_commit_csn: removing
0x7f7bf8200b40 20131004150021.988007Z#000000#002#000000
Oct 4 15:00:24 ldap-int1 slapd[24555]: syncrepl_entry: rid=102 be_add
cn=502296-xxxxxx,ou=aaaaa,ou=bbbb,o=cccc,c=dd (0)
... ...
ldap-ext2 receive the same modification an reply to ldap-int1 with new
cookie
ldap-int1 log
Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=103 NEW_COOKIE:
rid=103,sid=004,csn=20130304121522.188962Z#000000#000#000000;20131004082718.
3:40 a.m.
New subject: Antw: Re: another CSN too old N-WAY master
On Tue, 08 Oct 2013 12:15:56 +0200 "Ulrich Windl"
<Ulrich.Windl(a)rz.uni-regensburg.de> wrote
Are you sure you are chasing a real problem? AFAIK, in multi-master
sync, the
server that receives a change will send that change to all other nodes,
which, in turn, will also send the changes received to all other nodes.
It would be pretty inefficient if a provider in a MMR setup receives its own
modifications.
Given the fact that I'm also seeing missing entries in a MMR setup I suspect
there are indeed problems with the contextCSN.
Another one ITS#7710 which likely is limited to use of slapo-memberof but I'm
not really sure about that. (The data consistency issues happened without
slapo-memberof.)
Ciao, Michael.
4:55 a.m.
New subject: Antw: Re: another CSN too old N-WAY master
>> "Michael Ströder" <michael(a)stroeder.com>
schrieb am 08.10.2013 um 12:40 in
Nachricht
<dbc9e8c25a1bb1bac7905cb6950c87ad(a)srv1.stroeder.com>:
On Tue, 08 Oct 2013 12:15:56 +0200 "Ulrich Windl"
<Ulrich.Windl(a)rz.uni-regensburg.de> wrote
> Are you sure you are chasing a real problem? AFAIK, in multi-master sync,
the
> server that receives a change will send that change to all other nodes,
> which, in turn, will also send the changes received to all other nodes.
It would be pretty inefficient if a provider in a MMR setup receives its
own
modifications.
I agree, but from the logs my version seems to do exactly that, so maybe my
config is not correct, or the software has a bug. As it still does what it
should do, I don't care about the bug for the moment...
Given the fact that I'm also seeing missing entries in a MMR setup I
suspect
there are indeed problems with the contextCSN.
Another one ITS#7710 which likely is limited to use of slapo-memberof but
I'm
not really sure about that. (The data consistency issues happened without
slapo-memberof.)
Ciao, Michael.
12:41 a.m.
New subject: Antw: Re: another CSN too old N-WAY master
Do I open an issue about that with more log. Everyday we have consistency
problem.
This bug ( for me ) appear on "ou" with more than 120K entrie. Every entry
is check by another application every hour.
when are schedule the next release please ?
Thanks
2013/10/8 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de>
>>> "Michael Ströder" <michael(a)stroeder.com>
schrieb am 08.10.2013 um
12:40 in
Nachricht <dbc9e8c25a1bb1bac7905cb6950c87ad(a)srv1.stroeder.com>:
> On Tue, 08 Oct 2013 12:15:56 +0200 "Ulrich Windl"
> <Ulrich.Windl(a)rz.uni-regensburg.de> wrote
>> Are you sure you are chasing a real problem? AFAIK, in multi-master
sync,
> the
>> server that receives a change will send that change to all other nodes,
>> which, in turn, will also send the changes received to all other nodes.
>
> It would be pretty inefficient if a provider in a MMR setup receives its
own
> modifications.
I agree, but from the logs my version seems to do exactly that, so maybe my
config is not correct, or the software has a bug. As it still does what it
should do, I don't care about the bug for the moment...
>
> Given the fact that I'm also seeing missing entries in a MMR setup I
suspect
> there are indeed problems with the contextCSN.
>
> Another one ITS#7710 which likely is limited to use of slapo-memberof but
> I'm
> not really sure about that. (The data consistency issues happened without
> slapo-memberof.)
>
> Ciao, Michael.
1:07 a.m.
Lanfeust troy wrote:
Do I open an issue about that with more log. Everyday we have
consistency
problem.
This bug ( for me ) appear on "ou" with more than 120K entrie. Every entry
is check by another application every hour.
when are schedule the next release please ?
You could try to compile OPENLDAP_REL_ENG_2_4 branch snapshot from git.
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=tree;h=refs/hea...
Direct snapshot link:
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs...
Ciao, Michael.
3:23 a.m.
New subject: Antw: Re: another CSN too old N-WAY master
Lanfeust troy wrote:
Do I open an issue about that with more log. Everyday we have
consistency problem.
This bug ( for me ) appear on "ou" with more than 120K entrie. Every entry is
check by another application every hour.
when are schedule the next release please ?
Thanks
2013/10/8 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de
<mailto:Ulrich.Windl@rz.uni-regensburg.de>>
>>> "Michael Ströder" <michael(a)stroeder.com
<mailto:michael@stroeder.com>> schrieb am 08.10.2013 um 12:40 in
Nachricht <dbc9e8c25a1bb1bac7905cb6950c87ad(a)srv1.stroeder.com
<mailto:dbc9e8c25a1bb1bac7905cb6950c87ad@srv1.stroeder.com>>:
> On Tue, 08 Oct 2013 12:15:56 +0200 "Ulrich Windl"
> <Ulrich.Windl(a)rz.uni-regensburg.de
<mailto:Ulrich.Windl@rz.uni-regensburg.de>> wrote
>> Are you sure you are chasing a real problem? AFAIK, in multi-master sync,
> the
>> server that receives a change will send that change to all other nodes,
>> which, in turn, will also send the changes received to all other nodes.
>
> It would be pretty inefficient if a provider in a MMR setup receives its
own
> modifications.
I agree, but from the logs my version seems to do exactly that, so maybe my
config is not correct, or the software has a bug. As it still does what it
should do, I don't care about the bug for the moment...
If a server is receiving its own modifications that means your serverIDs are
not configured correctly. If your serverIDs are not configured correctly MMR
cannot work correctly. Fix your configuration.
>
> Given the fact that I'm also seeing missing entries in a MMR setup I
suspect
> there are indeed problems with the contextCSN.
>
> Another one ITS#7710 which likely is limited to use of slapo-memberof but
> I'm
> not really sure about that. (The data consistency issues happened without
> slapo-memberof.)
>
> Ciao, Michael.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7:12 a.m.
New subject: Antw: Re: another CSN too old N-WAY master
>> Howard Chu <hyc(a)symas.com> schrieb am 10.10.2013 um
12:23 in Nachricht
<5256800C.9010203(a)symas.com>:
Lanfeust troy wrote:
> Do I open an issue about that with more log. Everyday we have consistency
problem.
>
> This bug ( for me ) appear on "ou" with more than 120K entrie. Every entry
is
> check by another application every hour.
>
> when are schedule the next release please ?
> Thanks
>
>
> 2013/10/8 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de
> <mailto:Ulrich.Windl@rz.uni-regensburg.de>>
>
> >>> "Michael Ströder" <michael(a)stroeder.com
> <mailto:michael@stroeder.com>> schrieb am 08.10.2013 um 12:40 in
> Nachricht <dbc9e8c25a1bb1bac7905cb6950c87ad(a)srv1.stroeder.com
> <mailto:dbc9e8c25a1bb1bac7905cb6950c87ad@srv1.stroeder.com>>:
> > On Tue, 08 Oct 2013 12:15:56 +0200 "Ulrich Windl"
> > <Ulrich.Windl(a)rz.uni-regensburg.de
> <mailto:Ulrich.Windl@rz.uni-regensburg.de>> wrote
> >> Are you sure you are chasing a real problem? AFAIK, in multi-master
sync,
> > the
> >> server that receives a change will send that change to all other
nodes,
> >> which, in turn, will also send the changes received to all other
nodes.
> >
> > It would be pretty inefficient if a provider in a MMR setup receives
its
> own
> > modifications.
>
> I agree, but from the logs my version seems to do exactly that, so
maybe
my
> config is not correct, or the software has a bug. As it still does what
it
> should do, I don't care about the bug for the moment...
If a server is receiving its own modifications that means your serverIDs are
not configured correctly. If your serverIDs are not configured correctly MMR
cannot work correctly. Fix your configuration.
It could be due to an older version (openldap2-2.4.26-0.16.1 of SLES11 SP2)
being used...
>
> >
> > Given the fact that I'm also seeing missing entries in a MMR setup
I
> suspect
> > there are indeed problems with the contextCSN.
> >
> > Another one ITS#7710 which likely is limited to use of
slapo-memberof
but
> > I'm
> > not really sure about that. (The data consistency issues happened
without
> > slapo-memberof.)
> >
> > Ciao, Michael.
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
3458
days inactive
3474
days old
openldap-technical@openldap.org
14 comments
6 participants
participants (6)
-
Aaron Richton -
Howard Chu -
Lanfeust troy -
Michael Ströder -
Patrick Lists -
Ulrich Windl