[SERVER-50966] Modify PersistentTaskStore to support waiting for majority with the WaitForMajorityService Created: 16/Sep/20 Updated: 06/Dec/22 Resolved: 04/Mar/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Blake Oler | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | PM-234-M3, PM-234-O-unspecialized, PM-234-T-lifecycle | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Sharding
|
||||||||
| Participants: | |||||||||
| Story Points: | 1 | ||||||||
| Comments |
| Comment by Max Hirschhorn [ 04/Mar/21 ] |
|
I don't think this ticket is needed for resharding. We should be using kNoWaitWriteConcern with the PersistentTaskStore in all of the primary-only service Instances for resharding and using WaitForMajorityService before reaching out from the shards to the coordinator to update the document in the config.reshardingOperations collection. Closing this ticket as "Won't Do". CC yuhong.zhang, haley.connelly to ensure the kNoWaitWriteConcern part happens as part of |
| Comment by Blake Oler [ 16/Sep/20 ] |
|
It's unclear what the right answer is at the moment. I think both general approaches you've given are valid, but if we want to ensure that we wait for majority on the WaitForMajority service in the general sense, I feel that modifying the PersistentTaskStore itself seems like a better option. Whoever picks up this ticket will be tasked for figuring out the best approach. |
| Comment by Max Hirschhorn [ 16/Sep/20 ] |
|
blake.oler is there a proposal for adding this functionality? It wasn't clear to me whether we're trying to have PersistentTaskStore expose an async-compatible API where a SharedSemiFuture<void> would be returned. My other thought was for resharding to give PersistentTaskStore methods w=1 write concern so its call to waitForWriteConcern() is effectively a no-op and to use the WaitForMajorityService outside of PersistentTaskStore in order to chain the mongo::Futures together. |