[SERVER-56338] Allow resharding's CRUD application and session application to be concurrent Created: 25/Apr/21 Updated: 29/Oct/23 Resolved: 07/May/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 5.0.0-rc0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Max Hirschhorn | Assignee: | Max Hirschhorn |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Sharding 2021-05-17 |
| Participants: | |
| Story Points: | 1 |
| Description |
|
ReshardingOplogApplier first does a round of CRUD application followed by a round of session application. This is because the ReshardingOplogBatchPreparer mutates the repl::OplogEntries by calling setIsForReshardingSessionApplication(true) on them. If whether to do CRUD application versus session application was a property of the writer vector instead of the oplog entry itself, then tasks for both could be run concurrently. Allowing CRUD application and session application to be concurrent could reduce the overall makespan of applying a single batch. |
| Comments |
| Comment by Githook User [ 07/May/21 ] |
|
Author: {'name': 'Max Hirschhorn', 'email': 'max.hirschhorn@mongodb.com', 'username': 'visemet'}Message: |