Bug 813157 - Replication problems:when you create a HUB replica and it modified to Supplier then the RUV/replica id details were not updated in the db/memory
Replication problems:when you create a HUB replica and it modified to Suppli...
Status: CLOSED NOTABUG
Product: 389
Classification: Community
Component: Replication - General (Show other bugs)
1.2.0
ia64 Other
unspecified Severity high
: ---
: ---
Assigned To: Rich Megginson
Chandrasekar Kannan
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-17 02:02 EDT by rajendra
Modified: 2015-01-04 18:51 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-21 17:10:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
The attachment has having in details description of the problem and reproduce steps (174.31 KB, application/octet-stream)
2012-04-17 02:02 EDT, rajendra
no flags Details

  None (edit)
Description rajendra 2012-04-17 02:02:54 EDT
Created attachment 577884 [details]
The attachment has having  in details description of the problem and reproduce steps

Description of problem:

We have noticed two problems in the multiimaster replication environment of 389-1.2.0 code Base.  Here are the details below.
Problem 
=========
When the replica is modified (role change from HUB to Supplier), the replica id is updated from 65535 to newly given replica id (Ex: 15151) 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 following problems:

1.	Supplier and consumer still having the old replica ID (65535).
2.	The replication to the consumer always starts from the Min CSN and   supplier pushes all the entries from starting (If an entry is already replicated, the consumer just ignores it). Hence you can notice multiple log entries for a single operation in the access log. 
3.	Since the replication to consumer always starts from Min CSN, the new entries get replicated only after processing all old entries which would lead to delay in replication of new entries.

Kindly refer the attached document for more details .

Version-Release number of selected component (if applicable):

389-1.2.0 code Base.  

How reproducible:

Kindly refer the Attached document 


Actual results:

1) When the replica is modified (role change from HUB to Supplier),  the  Supplier and consumer still having the old replica Id insted of newly creaed Replica id in the db/memory.

2) Noticed multiple logs for single MOD operation in Access log.

Expected results:

1) When the replica is modified (i.e Role change from HUB to Supplier), the RUV entry in the db/memory needs to be updated with modified replica Id (i.e which is Supplier replica id)

2) There should not be multiple entries for single MOD operation in access logs
Comment 1 Rich Megginson 2012-04-17 09:18:13 EDT
Upstream ticket:
https://fedorahosted.org/389/ticket/341
Comment 2 Noriko Hosoi 2012-04-19 16:44:15 EDT
Did you have a chance to see this bug 750425 filed by Jyoti ranjan das (jyoti-ranjan.das@hp.com)?

https://bugzilla.redhat.com/show_bug.cgi?id=750425

The fix is in 389-ds-base-1.2.10 and newer.

Is it possible to try the reproducer steps with the version?
Comment 3 Noriko Hosoi 2012-05-21 17:10:05 EDT
(In reply to comment #2)
> Did you have a chance to see this bug 750425 filed by Jyoti ranjan das
> (jyoti-ranjan.das@hp.com)?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=750425
> 
> The fix is in 389-ds-base-1.2.10 and newer.
> 
> Is it possible to try the reproducer steps with the version?

Since we did not hear from you longer than a month, we are closing this bug for now.  Please feel free to reopen it once you get the information we asked for.
Thanks.

Note You need to log in before you can comment on or make changes to this bug.