[SERVER-82594] Verify IndexBuildCoordinator behavior during config change. Created: 30/Oct/23 Updated: 05/Dec/23 Resolved: 04/Dec/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Matthew Russotto | Assignee: | Gregory Noma |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Storage Execution
|
||||||||||||
| Sprint: | Execution Team 2023-11-27, Execution Team 2023-12-11 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
The IndexBuildCoordinator obtains the Replication Coordinator member configuration using replCoord->findConfigMemberByHostAndPort() in two places. Since the configuration could change before this call returns, it's not clear if this is conceptually a safe thing to do. We should verify that the IndexBuildCoordinator behaves correctly during configuration changes. (There's currently an actual race, which will be fixed by |
| Comments |
| Comment by Gregory Noma [ 04/Dec/23 ] |
|
Thanks to the removal of the PBWM, I believe (2) is also safe since the issue fixed by |
| Comment by Gregory Noma [ 17/Nov/23 ] |
|
There are two usages of ReplicationCoordinator::findConfigMemberByHostAndPort_deprecated in the index builds coordinator: (1) should be safe because it only checks whether the node is an arbiter, and converting a node to/from an arbiter requires restarting the node and removing it from the replica set. (2) requires a bit more thought because it checks whether the node is a voter, which can change with a reconfig. It uses this to determine whether the index build should be resumable or not: if the node it not a voter, then the index build cannot be resumable. This restriction was added as a part of |