[SERVER-53856] Resharding recipient primaries may skip session application for grouped op='i' oplog entries Created: 17/Jan/21  Updated: 29/Oct/23  Resolved: 28/Jan/21

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

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

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2021-01-25, Sharding 2021-02-08
Participants:
Story Points: 1

 Description   

insertOplogAndUpdateConfigForRetryable() is only called for the first op='i' oplog entry in the group.

if (op.isForReshardingSessionApplication()) {
    return insertOplogAndUpdateConfigForRetryable(opCtx, entryOrGroupedInserts.getOp());
}

https://github.com/mongodb/mongo/blob/cc8671bcf846a6aeda28a5cf81aea750c2fca4bd/src/mongo/db/s/resharding/resharding_oplog_applier.cpp#L409

Note that ReshardingOplogApplicationRules::_applyInsert_inlock() throws when the repl::OplogEntryOrGroupedInserts is a grouped insert to cause repl::OplogApplierUtils::applyOplogBatchCommon() to retry with the op='i' oplog entries ungrouped.



 Comments   
Comment by Githook User [ 28/Jan/21 ]

Author:

{'name': 'Randolph Tan', 'email': 'randolph@10gen.com', 'username': 'renctan'}

Message: SERVER-53856 Resharding recipient primaries may skip session application for grouped op='i' oplog entries
Branch: master
https://github.com/mongodb/mongo/commit/f83d7ef13e0418bec77b7bad012ddd89710f0d8c

Comment by Max Hirschhorn [ 19/Jan/21 ]

This ticket might also be a good opportunity to update the interface for the ReshardingOplogApplicationRules methods to take a const repl::OplogEntry& rather than a const repl::OplogEntryOrGroupedInserts&.

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