[SERVER-47094] Test a reconfig between scheduling an automatic reconfig and doing the automatic reconfig Created: 24/Mar/20 Updated: 29/Oct/23 Resolved: 18/Jun/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: | Vesselina Ratcheva (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Repl 2020-06-15, Repl 2020-06-29 |
| Participants: |
| Description |
|
When scheduling an automatic reconfig to remove a 'newlyAdded' field, we drop the replication coordinator mutex before actually doing the reconfig (which includes creating the new config for the reconfig). We use the memberId to note which member should have 'newlyAdded' removed. If another reconfig happens in parallel with the automatic reconfig, especially one that moves around the memberIndex of various nodes, it could be easy to add a bug that removes the wrong 'newlyAdded' field. To protect against this type of bug, we check that the configVersion and config term match after the scheduled reconfig actually constructs a new config. We should test this race condition explicitly. |
| Comments |
| Comment by Githook User [ 18/Jun/20 ] |
|
Author: {'name': 'Vesselina Ratcheva', 'email': 'vesselina.ratcheva@10gen.com', 'username': 'vessy-mongodb'}Message: |
| Comment by Githook User [ 17/Jun/20 ] |
|
Author: {'name': 'Vesselina Ratcheva', 'email': 'vesselina.ratcheva@10gen.com', 'username': 'vessy-mongodb'}Message: |
| Comment by Judah Schvimer [ 28/Apr/20 ] |
|
This should include tests that we remove the newlyAdded fields by memberId, not by memberIndex. So, if a node with memberIndex 1 has memberId 2, and both the node at memberIndex 1 and 2 have newlyAdded fields, when the node at memberIndex 1 leaves initial sync, it should have its newlyAdded field removed, not the node at memberIndex 2. |