[SERVER-53108] Fix OperationContext lifetime management in ReshardingOplogApplier and use batchSize > 1 Created: 30/Nov/20  Updated: 29/Oct/23  Resolved: 24/Dec/20

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 4.9.0

Type: Task Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Max Hirschhorn
Resolution: Fixed Votes: 0
Labels: PM-234-M2, PM-234-T-oplog-apply
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-53538 Clarify semantics of when destructor ... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2020-12-28
Participants:
Story Points: 2

 Description   

It is possible for the future returned by ReshardingDonorOplogIterator::getNext() to only become ready after opCtx would have been destructed. This won't happen while ReshardingDonorOplogIterator::_waitForNewOplog() always returns an immediately ready future, but would become an issue as soon as the returned future wasn't immediately ready. It isn't practical for ReshardingDonorOplogIterator::_waitForNewOplog() to always return an immediately ready future because the donor iterator may reached the end of the oplog buffer and need to wait for an insert notification from the ReshardingOplogFetcher.



 Comments   
Comment by Max Hirschhorn [ 24/Dec/20 ]

Author:

{'name': 'Max Hirschhorn', 'email': 'max.hirschhorn@mongodb.com', 'username': 'visemet'}

Message: SERVER-53108 Move batching logic into ReshardingDonorOplogIterator.

Raises the default value of the reshardingBatchLimitOperations server
parameter to 5,000 oplog entries to match that of the
replBatchLimitOperations server parameter.

Also introduces a reshardingBatchLimitBytes server parameter.
Branch: master
https://github.com/mongodb/mongo/commit/21418579095fa5ff44a851c2feb62ea4773ac3a6

Generated at Thu Feb 08 05:29:57 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.