[389-users] Re: Replication critical problem

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@lnf.infn.it

# 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@lnf.infn.it

# 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@lnf.infn.it

# 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@lnf.infn.it

# 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@lists.fedoraproject.org