Re: [389-users] Replication questions.

[Rich Megginson <rmeggins@xxxxxxxxxx>]

On 09/19/2011 12:46 PM, Reinhard Nappert wrote:

Hi, I have a multi-master setup with three masters. All of them are running 1.2.8.2. I had created and deleted the replication environment at least 3 times.

 

The current setup looks like the following.

 

Svr A has replication id 1, Srv B has the replication id 3 and Srv C has the id 4. The replication seems to work.

 

When I look into the dse.ldif files, I see the following:

 

Srv A:

dn: cn=replica,cn=o\3base,cn=mapping tree,cn=config
nsDS5ReplicaRoot: o=base
nsDS5ReplicaId: 1
nsDS5Flags: 1
nsDS5ReplicaType: 3
objectClass: top
objectClass: nsDS5Replica
cn: replica
...

nsDS5ReplicaReferral: ldap://SrvB:389/o=base
nsDS5ReplicaReferral: ldap://SrvC:389/o=base
numSubordinates: 2

dn: cn=SrvA2SrvB,cn=replica,cn=o\3base,cn=mapping tree,cn=config
objectClass: top
objectClass: nsDS5ReplicationAgreement
...

nsDS5ReplicaRoot: o=base
nsds50ruv: {replicageneration} 4e5ab509000000010000
nsds50ruv: {replica 3 ldap://SrvB:389} 4e775b74000000030000 4e77634c00000003
 0000
nsds50ruv: {replica 4 ldap://SrvC:389} 4e77621d000000040000 4e77634900000
 0040000
nsds50ruv: {replica 1 ldap://SrvA:389} 4e5ab517000000010000 4e77633d0000000
 10000
nsds50ruv: {replica 2 ldap://SrvC:389} 4e775c9c000000020000 4e775e4c00000
 0020000
nsruvReplicaLastModified: {replica 3 ldap://SrvB:389} 00000000
nsruvReplicaLastModified: {replica 4 ldap://SrvC:389} 00000000
nsruvReplicaLastModified: {replica 1 ldap://SrvA389} 00000000
nsruvReplicaLastModified: {replica 2 ldap://SrvC:389} 00000000

 

dn: cn=SrvA2SrvC,cn=replica,cn=o\3DUMC,cn=mapping tree,cn=config
...

nsds50ruv: {replicageneration} 4e5ab509000000010000
nsds50ruv: {replica 4 ldap://SrvC:389} 4e77621d000000040000 4e77634900000
 0040000
nsds50ruv: {replica 3 ldap://SrvB:389} 4e775b74000000030000 4e77634c00000003
 0000
nsds50ruv: {replica 1 ldap://SrvA:389} 4e5ab517000000010000 4e77634e0000000
 10000
nsds50ruv: {replica 2 ldap://SrvC:389} 4e775c9c000000020000 4e775e4c00000
 0020000
nsruvReplicaLastModified: {replica 4 ldap://SrvC:389} 00000000
nsruvReplicaLastModified: {replica 3 ldap://SrvB:389} 00000000
nsruvReplicaLastModified: {replica 1 ldap://SrvA:389} 00000000
nsruvReplicaLastModified: {replica 2 ldap://SrvC:389} 00000000

I did expect that the replicageneration is equal for all of the agreements (not only locally but also for the others).

 

When, I look at SrvB and SrvC, I do not seen any replicageneration: No nsds50ruv and nsruvReplicaLastModified values!

 

Srv B:

dn: cn=replica,cn=o\3base,cn=mapping tree,cn=config
nsDS5ReplicaRoot: o=base
nsDS5ReplicaId: 2
nsDS5Flags: 1
nsDS5ReplicaType: 3
objectClass: top
objectClass: nsDS5Replica
cn: replica
...

nsDS5ReplicaReferral: ldap://SrvA:389/o=base
nsDS5ReplicaReferral: ldap://SrvC:389/o=base
numSubordinates: 2

 

dn: cn=SrvB2SrvA,cn=replica,cn=o\3base,cn=mapping tree,cn=config
objectClass: top
objectClass: nsDS5ReplicationAgreement
...

nsDS5ReplicaRoot: o=base

 

dn: cn=SrvB2SrvC,cn=replica,cn=o\3DUMC,cn=mapping tree,cn=config
...

 

Srv3 entries look like:

 

Srv C:

dn: cn=replica,cn=o\3base,cn=mapping tree,cn=config
nsDS5ReplicaRoot: o=base
nsDS5ReplicaId: 3
nsDS5Flags: 1
nsDS5ReplicaType: 3
objectClass: top
objectClass: nsDS5Replica
cn: replica
...

nsDS5ReplicaReferral: ldap://SrvB:389/o=base
nsDS5ReplicaReferral: ldap://SrvA:389/o=base
numSubordinates: 2

 

dn: cn=SrvC2SrvA,cn=replica,cn=o\3base,cn=mapping tree,cn=config
objectClass: top
objectClass: nsDS5ReplicationAgreement
...

nsDS5ReplicaRoot: o=base

 

dn: cn=SrvC2SrvB,cn=replica,cn=o\3DUMC,cn=mapping tree,cn=config
...

 

So, my questions are:

Why are the two attributes nsds50ruv and nsruvReplicaLastModified missing in the agreement objects on SrvB and SrvC.

Not sure.  But the main ones are the ones in the database in the nsTombstone entry (see below).

Secondly, why do I still see those old values for nsds50ruv and nsruvReplicaLastModified  in SrvA. This looks strange to me.

Deleting a replica does not clean up these values.  For dse.ldif you'll have to shutdown the server, edit that entry in dse.ldif to remove the old values, and restart the server.

 

Even more confusing is that I see those attributes if I read the dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=base entry. Why are those nsds50ruv with old replicagenerations still there? At least the replicageneration is identical on all three boxes.

If replicageneration is not the same across all servers, replication should not work.

Note that deleting a replica does not clean up this ruv metadata from the nsTombstone entry.  See http://directory.fedoraproject.org/wiki/Howto:CLEANRUV

 

SrvA:

dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=base
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 4e5ab509000000010000
nsds50ruv: {replica 4 ldap://SrvC:389} 4e77621d000000040000 4e7770f200000
 0040000
nsds50ruv: {replica 3 ldap://SrvB:389} 4e775b74000000030000 4e77860b00000003
 0000
nsds50ruv: {replica 1 ldap://SrvA:389} 4e5ab517000000010000 4e77859d0000000
 10000
nsds50ruv: {replica 2 ldap://SrvC:389} 4e775c9c000000020000 4e775e4c00000
 0020000
o: umc
nsruvReplicaLastModified: {replica 4 ldap://SrvC:389} 4e7770f1
nsruvReplicaLastModified: {replica 3 ldap://SrvB:389} 4e77860a
nsruvReplicaLastModified: {replica 1 ldap://SrvA:389} 4e77859c
nsruvReplicaLastModified: {replica 2 ldap://SrvC:389} 00000000

 

SrvB:

dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=base
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 4e5ab509000000010000
nsds50ruv: {replica 1 ldap://SrvA:389} 4e5ab517000000010000 4e77859d0000000
 10000
nsds50ruv: {replica 4 ldap://SrvC:389} 4e77621d000000040000 4e7770f200000
 0040000
nsds50ruv: {replica 2 ldap://SrvC:389} 4e775c9c000000020000 4e775e4c00000
 0020000
nsds50ruv: {replica 3 ldap://SrvB:389} 4e775b74000000030000 4e77860b00000003
 0000
o: umc
nsruvReplicaLastModified: {replica 1 ldap://SrvA:389} 4e77859c
nsruvReplicaLastModified: {replica 4 ldap://SrvC:389} 4e7770f1
nsruvReplicaLastModified: {replica 2 ldap://SrvC:389} 00000000
nsruvReplicaLastModified: {replica 3 ldap://SrvB:389} 4e778609

 

 

SrvC:

dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=base
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 4e5ab509000000010000
nsds50ruv: {replica 3 ldap://SrvB:389} 4e775b74000000030000 4e77860b00000003
 0000
nsds50ruv: {replica 4 ldap://SrvC:389} 4e77621d000000040000 4e7770f200000
 0040000
nsds50ruv: {replica 1 ldap://SrvA:389} 4e5ab517000000010000 4e77859d0000000
 10000
nsds50ruv: {replica 2 ldap://SrvC:389} 4e775c9c000000020000 4e775e4c00000
 0020000
o: umc
nsruvReplicaLastModified: {replica 3 ldap://SrvB:389} 4e77860a
nsruvReplicaLastModified: {replica 4 ldap://SrvC:389} 4e7770f1
nsruvReplicaLastModified: {replica 1 ldap://SrvA:389} 4e77859c
nsruvReplicaLastModified: {replica 2 ldap://SrvC:389} 00000000

 

 

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users