-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Cluster Scalability
-
ALL
-
ClusterScalability Jun9-Jun23
-
200
-
None
-
3
-
TBD
-
None
-
None
-
None
-
None
-
None
-
None
SERVER-106349 made ShardRemote::runAggregation return postBatchResumeToken even when the batch is not empty so that 'reshardProgressMark' oplog entries get inserted even when the cursor hasn't reached the end of the oplog or is still finding matching oplog entries. However, it is incorrect to consult the postBatchResumeToken when the batch is non-empty because by design the postBatchResumeToken is the highest _id seen in the collection scan. The document with that _id may or may not be part of the batch itself.
- It could be that the document got filtered out from the batch due to $match.
- It could be that the document just hasn't been included yet in the batch due to the response size limit.
Given this, we should revert the changes to ShardRemote::runAggregation and update the ReshardingOplogFetcher unit tests accordingly.
- is related to
-
SERVER-49897 Insert no-op entries into oplog buffer collections for resharding so resuming is less wasteful
-
- Closed
-
-
SERVER-106349 Make ReshardingOplogFetcher create 'reshardProgressMark' oplog entries at least once within configured interval if the recipient is in the applying state and has been configured to estimate remaining time based on the exponential moving average
-
- Closed
-
- related to
-
SERVER-106555 Make ReshardingOplogBatchApplier update the average time to apply oplog entries after each batch
-
- Closed
-