Re: [389-users] Replication questions.

Reinhard Nappert <rnappert@xxxxxxxxxxx> · Mon, 19 Sep 2011 15:00:46 -0400

Thanks for the quick response, Rich.

Good to know that there is a procedure for cleaning up the old 
ruvs. This probably helps, when I want to troubleshoot replication issues. 
Getting rid of old data is helpful.

-Reinhard

From: Rich Megginson 
[mailto:rmeggins@xxxxxxxxxx] 
Sent: Monday, September 19, 2011 2:54 
PM
To: General discussion list for the 389 Directory server 
project.
Cc: Reinhard Nappert
Subject: Re: [389-users] 
Replication questions.

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