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@redhat.com]
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@lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users