[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. |