Bug 182638 - Multi-replication nodes not replicating both ways
Multi-replication nodes not replicating both ways
Status: CLOSED WORKSFORME
Product: Red Hat Directory Server
Classification: Red Hat
Component: Replication - General (Show other bugs)
7.1
All Linux
medium Severity medium
: DS8.0
: ---
Assigned To: Noriko Hosoi
Chandrasekar Kannan
tigerwoods.sfbay.redhat.com
:
Depends On:
Blocks: 152373 240316
  Show dependency treegraph
 
Reported: 2006-02-23 14:53 EST by Ben Le
Modified: 2015-01-04 18:19 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-23 19:22:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ben Le 2006-02-23 14:53:49 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060124 Firefox/1.5.0.1

Description of problem:
We are currently running our directory servers in a multi-replication configuration. Meaning, if we create a record in node A we would be expect to see it appear in node B and if node B we delete a record we would expect to see it deleted from node A.  
 
The problem we are having, depending on which Node intializes the other, we are not able to achive multi-replication between the nodes. For instance, node A intializes node B and node A is able to replicate data changes to node B. However, if you make a data change to node B it does NOT appear in node A.  



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


How reproducible:
Always

Steps to Reproduce:
1. After setup Multi-replicaton on both servers.
2. Restart both servers.
3. Re-Initialize consumer.
4. Then update or delete the entry on the node B.



Actual Results:  The data change on the node B doesn't appear in node A.

Additional info:
Comment 1 Rich Megginson 2006-02-23 15:18:53 EST
Do you have any errors in the node B error log?
What steps were followed in 1)?  You should have configured a change log on each
server, configured each server to be a multiple master, assigned each one a
unique replica ID number, created a replication consumer entry on each server,
created a replication agreement with the other master.
2) - you do not need to restart the servers
3) - consumer?  Both servers are masters, right?  You should only have to
initialize once.
Comment 2 Orla Hegarty 2006-02-27 18:51:18 EST
Per today's bug council; To will reproduce this bug. Setting target tracking and
target milestone to 7.2 
Comment 3 To Ngan 2006-12-12 19:13:27 EST
Ben, is this still an issue?
Comment 4 Ben Le 2006-12-13 11:41:43 EST
To,
Customer is no longer mentioned about this issue solution. It should be good to
fix this issue in the future release.
Comment 5 To Ngan 2007-01-04 16:51:37 EST
I can reproduce the issue following the steps.  At step 3, I issued "Initial
Consumer" on one of the 2 masters.

Since then replication only works from that master to the other, but not the
other way around.

I see the following error mesgs on the master where replication is not syncing:

[04/Jan/2007:13:21:45 -0800] NSMMReplicationPlugin -
multimaster_be_state_change: replica dc=dsqa,dc=sjc2,dc=redhat,dc=com is coming
online; enabling replication
[04/Jan/2007:13:21:45 -0800] NSMMReplicationPlugin - replica_reload_ruv:
Warning: new data for replica dc=dsqa,dc=sjc2,dc=redhat,dc=com does not match
the data in the changelog.
 Recreating the changelog file. This could affect replication with replica's 
consumers in which case the consumers should be reinitialized.
[04/Jan/2007:13:22:38 -0800] agmt="cn=repag1" (shadowfoot:9900) - Can't locate
CSN 459d6fc1000000010000 in the changelog (DB rc=-30990). The consumer may need
to be reinitialized.
Comment 6 To Ngan 2007-01-04 16:58:29 EST
More notes:
-Build used to reproduce: DS 71 SP3 on RHEL 4.
-Before step 2, I verified sycns are happening both ways, and the db was in sync.
-Noriko thinks step 3 would still keep both masters in sync, and should not
require a "Initialize Consumer" from master B for replication to continue to
work both ways.
Comment 7 Noriko Hosoi 2007-01-04 17:45:28 EST
To and Noriko did some more experiments:
We 
Steps to Reproduce:
1. After setup Multi-replicaton on both servers.
2. Restart both servers.
3. Run Consumer initialization on A.
4. Then update or delete the entry on the node B.
Actual Results:  The data change on the node B doesn't appear in node A.

We removed the changelog on B.  Then, the operations done against B were
replicated to A.  As To put in the comment #5, this error is caused by the
inconsistency between the changelog and the data in the main db.

First, I thought if B is reinitialized by A, the changelog on B should be
cleaned up.  But if there are some changes only recorded on B, the information
will be lost.  To prevent it, the initialization does not touch the changelog.

So, there are two ways to resolve the inconsistency.  1) If you don't care the
changes on B, remove the changelog on B (see
http://www.redhat.com/docs/manuals/dir-server/ag/7.1/replicat.html#1110322).  2)
If changes made on B need to be replicated to A, run consumer initialization on
B, as well.
Comment 8 Chandrasekar Kannan 2007-07-25 15:09:36 EDT
DS7.2 is not a valid milestone anymore. Anything thats set to DS7.2 should be
set to DS8.0. Will make further changes per bug council on 07/24/2007, after this.

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