[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: |
|
||||||||||||||||||||
| Assigned Teams: |
Replication
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||
| 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]) 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 |
| 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. |