-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Cluster Scalability
-
ClusterScalability Jun23-Jul6
-
200
-
None
-
3
-
TBD
-
None
-
None
-
None
-
None
-
None
-
None
Due to SERVER-106550, the ReshardingOplogFetcher now only creates 'reshardProgressMark' oplog entries when the cursor has reached the end of the oplog since ShardRemote::runAggregation only returns postBatchResumeToken when the batch is empty. So unless the cursor has reached the end of the oplog, the ReshardingOplogFetcher no longer creates at least one 'reshardProgressMark' oplog entry every reshardingExponentialMovingAverageTimeToFetchAndApplyIntervalMillis. So if the ReshardingOplogBatchApplier continued to update the average time to apply oplog entries only upon seeing 'reshardProgressMark' oplog entries, the average would remain uninitialized until the cursor has reached the end of the oplog, which would prevent us from being able to estimate the remaining time based on average time to fetch and apply oplog entries prior to that. To work around that, instead ReshardingOplogBatchApplier should also update the average time to apply oplog entries after applying each oplog batch.
- is related to
-
SERVER-106550 ShardRemote::runAggregation should only return postBatchResumeToken when the batch is empty
-
- Closed
-
- related to
-
SERVER-106712 Prevent assert.soon in ReshardingTestFixture from timing out
-
- Closed
-