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:rmegg...@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-us...@lists.fedoraproject.org<mailto:389-us...@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
