[SERVER-56335] Increment the number of oplog entries applied by one when recipient completely catches up to donor Created: 25/Apr/21  Updated: 29/Oct/23  Resolved: 04/May/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 5.0.0-rc0

Type: Task Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Janna Golden
Resolution: Fixed Votes: 0
Labels: PM-234-M3, PM-234-T-autocommits
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   

The ReshardingDonorOplogIterator intentionally doesn't return the op='n' final resharding oplog entry. Not returning the final resharding oplog entry ensures the recipient, when resuming, would be guaranteed to come across the oplog entry again in its local oplog buffer and realize it had already finished applying all of the oplog entries.

However, the current behavior leads the number of oplog entries fetched to always be greater than the number of oplog entries applied, even when resharding completes successfully. This is due to how the op='n' final resharding oplog entries are accounted for in the number of oplog entries fetched, but are not accounted for in the number of oplog entries applied. Incrementing the in-memory counter by 1 for the number of oplog entries applied when ReshardingOplogApplier::_currentBatchToApply is empty would correct this discrepancy. The on-disk value for 'numEntriesApplied' in the progress_applier collection must not be incremented by 1.



 Comments   
Comment by Githook User [ 04/May/21 ]

Author:

{'name': 'jannaerin', 'email': 'golden.janna@gmail.com', 'username': 'jannaerin'}

Message: SERVER-56335 Increment the number of oplog entries applied by 1 twhen resharding recipient catches up to donor to account for final oplog entry
Branch: master
https://github.com/mongodb/mongo/commit/fd0454d592b86062970defb025e2b2c792d110f4

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