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