On 03/22/2016 11:31 AM, Dael Maselli
wrote:
It happens sometimes, maybe you delete a value and works then
delete another value of the same attribute in the same entry after
2-3 seconds and it is deleted only on the master you are
connected.
We noticed it months ago with one operational attribute, the
password expire time, but we though it was a special case. Now it
happens every attributes.
Here is the original entry:
# extended LDIF
#
# LDAPv3
# base <dc=infn,dc=it> with scope subtree
# filter: uid=dmaselli
# requesting: description mail
#
# 6e4b0a83-4067-4966-a4c1-5d4797114fef, People, infn.it
dn:
infnUUID=6e4b0a83-4067-4966-a4c1-5d4797114fef,ou=People,dc=infn,dc=it
description: asd
mail: dael.maselli@xxxxxxxxxxx
# ad5f018b-5a80-41d8-a5d9-027c3573d6e5, People,
lnf.infn.it
dn:
infnUUID=ad5f018b-5a80-41d8-a5d9-027c3573d6e5,ou=People,dc=lnf,dc=infn,dc=
it
description: zxc
mail: dael.maselli@xxxxxxxxxxx
# search result
search: 2
result: 0 Success
# numResponses: 3
# numEntries: 2
Then I delete the "description: asd" from the first entry and on
the master I'm connected it works a follow:
# extended LDIF
#
# LDAPv3
# base <dc=infn,dc=it> with scope subtree
# filter: uid=dmaselli
# requesting: description uid mail
#
# 6e4b0a83-4067-4966-a4c1-5d4797114fef, People,
infn.it
dn:
infnUUID=6e4b0a83-4067-4966-a4c1-5d4797114fef,ou=People,dc=infn,dc=it
uid: dmaselli
mail: dael.maselli@xxxxxxxxxxx
# ad5f018b-5a80-41d8-a5d9-027c3573d6e5, People,
lnf.infn.it
dn:
infnUUID=ad5f018b-5a80-41d8-a5d9-027c3573d6e5,ou=People,dc=lnf,dc=infn,dc=
it
description: zxc
uid: dmaselli
mail: dael.maselli@xxxxxxxxxxx
# search result
search: 2
result: 0 Success
# numResponses: 3
# numEntries: 2
On all other servers (masters and slaves) it is as it was before.
How long does it take for it to be replicated to all the
masters/consumers?
Are all the masters under "load" at this time?
Are you using fractional replication?
Thanks,
Mark
Thank you!
On 22/03/16 16:09, Ludwig Krispenz
wrote:
On 03/22/2016 03:34 PM, Dael Maselli wrote:
Our authentication and authorization
infrastructure is based on 3 multi-master server and 2 slaves
with 35 databases each, all have the following version of 389:
389-ds-1.2.2-1.el6.noarch
389-ds-base-1.2.11.15-60.el6.x86_64
389-ds-base-libs-1.2.11.15-60.el6.x86_64
389-ds-console-1.2.6-1.el6.noarch
389-ds-console-doc-1.2.6-1.el6.noarch
389-dsgw-1.1.11-1.el6.x86_64
We are experiencing a strange behavior, replication of new
attributes, new values of attributes and modification of
values are propagated correctly, but deleting a value of
attribute are propagated randomly, no matter of what master
starts the modification or what database we modify, big or
little ones.
did the problem just start recently or have you just noticed it
?
what do you mean by propagated randomly ? sometimes or always
but different on different replicas ?
can you give an example of an entry which is the same on all
servers and how it looks like after the del of an value ?
I tried reinitializing database from one master but the
problem persists, no errors are logged.
Now our server are not synchronized and this is, as you can
imagine, very bad ;-)
Thank you very much!
Regards,
Dael Maselli.
--
___________________________________________________________________
Dael Maselli --- INFN-LNF Computing Service -- +39.06.9403.2214
___________________________________________________________________
* http://www.lnf.infn.it/~dmaselli/ *
___________________________________________________________________
Democracy is two wolves and a lamb voting on what to have for lunch
___________________________________________________________________
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx
|
