[SERVER-63880] [Retryability] Make resharding handle applyOps oplog entries with WouldChangeOwningShard sentinel noop entry Created: 22/Feb/22  Updated: 29/Oct/23  Resolved: 23/Mar/22

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

Type: Task Priority: Major - P3
Reporter: Cheahuychou Mao Assignee: Cheahuychou Mao
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Issue split
split from SERVER-60525 [Retryability] Make retryable write s... Closed
Related
related to SERVER-64751 ApplyOpsCommandInfo::areOpsCrudOnly()... Open
Backwards Compatibility: Fully Compatible
Sprint: Sharding NYC 2022-03-21, Sharding NYC 2022-04-04
Participants:

 Description   

SERVER-59186 makes mongos use internal transactions to handle WouldChangeOwningShard update and findAndModify. As a result, mongos no longer uses the client txnNumber to run the transaction that handles the WouldChangeOwningShard error. To make a retry still fail with an IncompleteTransactionHistory error, SERVER-63366 introduced the notion of WouldChangeOwningShard sentinel operation entry to trigger to an IncompleteTransactionHistory error on retries. So applyOps oplog entries for retryable internal transactions can now contain a noop (i.e. no CRUD) operation, this is expected to lead to an error during resharding since it doesn't expect to see a non CRUD operation in an applyOps oplog entry.



 Comments   
Comment by Githook User [ 23/Mar/22 ]

Author:

{'name': 'Cheahuychou Mao', 'email': 'mao.cheahuychou@gmail.com', 'username': 'cheahuychou'}

Message: SERVER-63880 Make resharding handle applyOps oplog entries with WouldChangeOwningShard sentinel noop entry
Branch: master
https://github.com/mongodb/mongo/commit/7c4fa21deaee0f1e0280a1dc129c7e5da82df99b

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