Hi,
We have noticed two problems in the multiimaster replication environment of
389-1.2.0 code base. Can you please provide any insight on these issues.
Problem 1:
When the replica is modified (role change from HUB to Supplier), the replica id
is updated from 65535 to newly given replica id in the dse.ldif file. But the
RUV entry in the db/memory still having the old replica id (i.e 65535 )
instead of newly provided replica id .This caused the problem of supplier and
consumer still having the old replica ID.
The reproducer details are given below:
1. Create the Supplier instance
2. From admin GUI , check "Enable Changelog" of Supplier Settings
3. Specify the location of update history log in "Replication Changelog"
4. Check "Enables Replica" of Replica Settings
5. Select "Hub" in Replica Role and click Save ---> nsDS5ReplicaId:65535 is
added in dse.ldif file. // this is expected
6. Select "Single Master" in Replica Role and specify 13089 in ReplicaID box,
and click Save. ---> nsDS5ReplicaId:13089 is added in dse.ldif file. // this is
expected
7. Create the Consumer instance
8. Create the entry for Supplier DN (cn=replication manager,cn=config)
9. Specify the entry created at step #2 above for Supplier DN box in
replication configuration.
10. Select "Dedicated Consumer" as the replica role, and click Save --->
nsDS5ReplicaId:65535 is added in dse.ldif file. // this is expected
11. Create replication agreement between Supplier and Consumer.
12. Initialize the Consumer in Supplier.
13. Search the replication infromation (RUV) in Supplier ---> no replica ID
hit // This is normal
14. Search the replication information (RUV) in Consumer ---> no replica ID
hit // This is normal
15. Add an entry for Supplier
16. Search the replication information (RUV) in Supplier ---> replica
ID:65535 is hit // This is NOT normal. The replica id 13089 should be hit
because of the step #6 above
// This as if the memory content is not change while dse.ldif is changed.
17. Search the replication information (RUV) in Consumer ---> replica
ID:65535 is hit // This is NOT normal. // 13089 should be hit because of the
step #6 above
// This as if the memory content is not change while dse.ldif is changed.
Problem2:
In the above setup we have noticed below issue also.
When we perform a MOD operation on supplier, Multiple MOD operations are logged
in the access log for same modify operation (i.e single operation). For
instance, the mod operation for uid=0060628 below was requested only once, but
multiple MOD entries were logged in access log. And also modification update
from Supplier to Consumer is taking around 10 min.
[02/Apr/2012:22:56:24 +0900] conn=84924065 op=68 MOD
dn="uid=0060628,ou=people,dc=xxxx,dc=xxx,dc=xxx"
[02/Apr/2012:22:56:24 +0900] conn=84924065 op=72 MOD
dn="uid=0060628,ou=people,dc=xxx,dc=xxx,dc=xxx"
[02/Apr/2012:23:07:53 +0900] conn=84925508 op=1951 MOD
dn="uid=0060628,ou=people,dc=xxx,dc=xxx,dc=xxx"
[02/Apr/2012:23:07:53 +0900] conn=84925508 op=2314 MOD
dn="uid=0060628,ou=people,dc=xxx,dc=xxx,dc=xxx"
[02/Apr/2012:23:18:23 +0900] conn=84927516 op=69 MOD
dn="uid=0060628,ou=people,dc=xxx,dc=xxx,dc=xxx"
[02/Apr/2012:23:18:23 +0900] conn=84927516 op=73 MOD
dn="uid=0060628,ou=people,dc=xxx,dc=xxx,dc=xxx"
Thanks in Advance,
Best Regards,
Rajendra
--
389 users mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/389-users
