[SERVER-7366] Create a random seed on rs.initiate() to avoid merging replica sets Created: 16/Oct/12  Updated: 06/Dec/22  Resolved: 10/Feb/16

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 2.2.0
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Grégoire Seux Assignee: Backlog - Replication Team
Resolution: Duplicate Votes: 3
Labels: elections
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
duplicates SERVER-22287 Merging replica sets with replication... Closed
is duplicated by SERVER-7477 Calling rs.initiate() on 2 nodes when... Closed
Related
Assigned Teams:
Replication
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:
Case:

 Description   

Let's have two servers we want to put in the same replicaset A and B

On A : rs.initiate( [a config whith only A])
On B : rs.initiate( [a config whith only B])

then on A : rs.reconfig([a config with A and B])

A will have two primaries in the replicaset. B will have only himself.

The reconfig on A should fail instead of work to avoid this situation



 Comments   
Comment by Spencer Brody (Inactive) [ 10/Feb/16 ]

This issue was fixed in pv1 by SERVER-22287.

Comment by Grégoire Seux [ 18/May/13 ]

Is there any plan on this? it really limits the capacity to automatically drive replicaset creation.

Comment by Kristina Chodorow (Inactive) [ 16/Oct/12 ]

Good idea, I think that would work.

Comment by Grégoire Seux [ 16/Oct/12 ]

You could have a "seed" issued when rs.initiate is called and this seed would be propagated when to new members. If a new member already has a seed, comparison is done and raises issue accordingly.

Comment by Kristina Chodorow (Inactive) [ 16/Oct/12 ]

I don't think replica sets are designed to make this work. Theoretically, this could take the current config on A and compare it to the config on B. If they match, the reconfig succeeds, if they don't match, it fails. However, A could be a few versions ahead of B (which would be perfectly valid), then A's current config wouldn't match B's. We could keep a record of every previous config we've ever had, but that seems silly. We could insist that the configs match if the versions match, but then all you have to do is rs.initiate(); rs.reconfig() on A to circumvent that check.

I agree that this is suboptimal, but other than making the rs API make more sense, I'm not sure what we can do about it.

Generated at Thu Feb 08 03:14:20 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.