Bug 624442
| Summary: | MMR: duplicate replica ID | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] 389 | Reporter: | reinhard nappert <rnappert> | ||||
| Component: | Directory Server | Assignee: | Noriko Hosoi <nhosoi> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Viktor Ashirov <vashirov> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 1.1.2 | CC: | amsharma, andrey.ivanov, jgalipea, msauton, nhosoi | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-12-07 16:31:58 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 639035 | ||||||
| Attachments: |
|
||||||
Thanks for the bug report. I could reproduce the problem. [12/Jan/2011:14:13:36 -0800] NSMMReplicationPlugin - agmt="cn=agmt1" (kiki:10390): Unable to aquire replica: the replica has the same Replica ID as this one. Replication is aborting. [12/Jan/2011:14:13:36 -0800] NSMMReplicationPlugin - agmt="cn=agmt1" (kiki:10390): Incremental update failed and requires administrator action Created attachment 473440 [details]
git patch file (master)
Description: Each replica has an RUV tombstone entry in the
backend db, which keeps nsds50ruv attribute values as follows:
nsds50ruv: {replicageneration} <replica_generation_csn>
nsds50ruv: {replica <rid> ldap://<host>:<port>} <last_modified>
...
When the replica is deleted, the RUV tombstone entry remains
in the db. Then if the replica is added back with the different
replica id <rid-2>, the original nsds50ruv value {replica <rid>
ldap://<host>:<port>} was not updated. This caused the problem
if the counter replica server happened to get the same replica
id <rid> that this server original had.
This patch compares the replica id <rid> in the RUV tombstone
entry with the new id <rid-2>. If they don't match, recreate
the RUV tombstone entry.
Reviewed by Nathan (Thanks!!!) Pushed to master. $ git merge work Updating 7dfe817..d05faee Fast-forward ldap/servers/plugins/replication/repl5_replica.c | 46 ++++++++++++++++++--- ldap/servers/plugins/replication/repl5_ruv.c | 4 +- 2 files changed, 42 insertions(+), 8 deletions(-) $ git push Counting objects: 15, done. Delta compression using up to 4 threads. Compressing objects: 100% (8/8), done. Writing objects: 100% (8/8), 1.60 KiB, done. Total 8 (delta 6), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 7dfe817..d05faee master -> master Steps to verify.
1. Set up 2-way MMR: Master 1 with Replica ID 1
Master 2 with Replica ID 2
2. Disable Replica on the both Master 1 and 2
3. Setup MMR again: Master 1 with Replica ID 2
Master 2 with Replica ID 1
4. Create an agreement on Master 1 and 2
5. Initialize consumer on Master 1
If the initializing consumer is successful, the bug has been verified.
Test Steps =========== 1. I have setup 2-way MMR between M1 and M2 with M1 - Replica ID -11 M2 - Replica ID -12 2. Then , I have deleted the replication suffixes from both M1 and M2. 3. Recreated the suffixes and assigned the Replica IDs as: M1 - Replica ID -12 M2 - Replica ID -11 4. Replication is happening properly without and error. Hence, marking the bug as VERIFIED. should this bugzilla 624442 closed? the patch in https://bugzilla.redhat.com/attachment.cgi?id=473440 has been in 389-ds-base for some time, it is for sure in 389-ds-base-1.2.11.15-48 the salesforce case number 01336038 is about RHDS 8.2 |
Let's say, I just have two MM A <--> B. I start configuring the replica and agreement on A and assign id 1. Then I do the same for B with the id 2. Everything is fine. Then, I disable on both boxes the replication. Then, I start setting the same thing up, but I start with B and assign 1 as id. A gets 2 as id assigned. Now, the replication fails with the message: "Unable to acquire replica: error: duplicate replica ID detected" I am pretty sure that it has to do with the RUV entry "nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=your,dc=suffix", because it still shows: dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff, dc=your,dc=suffix objectClass: top objectClass: nsTombstone objectClass: extensibleobject nsds50ruv: {replicageneration} 4c6445e4000000010000 nsds50ruv: {replica 1 ldap://A:389} nsds50ruv: {replica 2 ldap://B:389} nsruvReplicaLastModified: {replica 1 ldap://A:389} 00000000 nsruvReplicaLastModified: {replica 2 ldap://B:389} 00000000 My replica configuration objects use the correct ids (1 for B) and (2 for A). All this said, I believe the server should internally delete the RUV entry, once the replica configuration object is deleted.