[SERVER-30553] Handle duplicate oplog entries in transaction write history for findAndModify Created: 08/Aug/17  Updated: 27/Oct/23  Resolved: 15/Sep/17

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

Type: Task Priority: Major - P3
Reporter: Randolph Tan Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Sharding
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2017-10-02
Participants:

 Description   

findAndModify retry design is based on storing the post/pre-image of the operation on a separate no-op oplog entry along with the actual write oplog entry. In normal cases, the retry logic can expect to see only a max of 2 oplog entries. However, due of migrations, there can be duplicate oplog entries (for the same write, but different timestamp). The findAndModify retry logic should be able to handle this.



 Comments   
Comment by Randolph Tan [ 15/Sep/17 ]

This is no longer an issue with the current code since the oplog it is now design such that the pre/post image oplog will not be discoverable (without scanning the entire oplog) unless the write associated with it is linked to it.

Generated at Thu Feb 08 04:24:13 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.