[SERVER-47363] Define correct use of MemberIds in Atlas workflow tests Created: 06/Apr/20 Updated: 29/Oct/23 Resolved: 03/Jul/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.7.0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Judah Schvimer | Assignee: | Suganthi Mani |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||
| Sprint: | Repl 2020-06-29, Repl 2020-07-13 | ||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||
| Description |
|
MemberIds should uniquely identify nodes, even across config versions. Therefore reusing MemberIds can be dangerous. The current Atlas workflow tests will do whatever Atlas does today, but we should decide what the correct workflow is and change the tests to match that so Atlas can implement the correct workflow. |
| Comments |
| Comment by Githook User [ 03/Jul/20 ] |
|
Author: {'name': 'Suganthi Mani', 'email': 'suganthi.mani@mongodb.com', 'username': 'smani87'}Message: |
| Comment by Judah Schvimer [ 27/May/20 ] |
|
I think that is the safest recommendation. |
| Comment by William Schultz (Inactive) [ 27/May/20 ] |
|
To clarify, going forward will we be recommending that MemberId be effectively treated as a globally (in time and space) unique id (e.g. a UUID)? |
| Comment by Judah Schvimer [ 20/May/20 ] |
|
Yes, I agree with the above, and think it's a good model for thinking about nodes and member ids. |
| Comment by William Schultz (Inactive) [ 20/May/20 ] |
|
judah.schvimer Do you agree that a "node" as used in the ticket description, should, for the most part, correspond to a particular set of data files? For example, as you mentioned elsewhere, if you want to resync a node, you could remove the node first, and then add back a new node with a new, unused member id. This would uphold the assumption that each member id maps to a unique set of data files. |
| Comment by Judah Schvimer [ 01/May/20 ] |
|
We should also document this more widely for all users in our documentation. |