[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: SERVER-47094 Test doing a reconfig between scheduling an automatic reconfig and its execution
Branch: master
https://github.com/mongodb/mongo/commit/834a3c49d9ea9bfe2361650475158fc0dbb374cd

Comment by Githook User [ 17/Jun/20 ]

Author:

{'name': 'Vesselina Ratcheva', 'email': 'vesselina.ratcheva@10gen.com', 'username': 'vessy-mongodb'}

Message: SERVER-47094 Test that we remove 'newlyAdded' by member id, not member index
Branch: master
https://github.com/mongodb/mongo/commit/728a6e9d5d70885314e1e54619b6caffd1498999

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.

Generated at Thu Feb 08 05:13:17 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.