[SERVER-41074] Don't migrate prePostImageDoc session entries for CRUD operations outside of current migration range Created: 09/May/19 Updated: 29/Oct/23 Resolved: 17/May/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.12 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Blake Oler | Assignee: | Randolph Tan |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Sprint: | Sharding 2019-05-20, Sharding 2019-06-03 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
Problem StatementWhen migrating retryable CRUD op session entries, we generate a prePostImage oplog entry if necessary. Later in the process, we filter out these CRUD op entries, but not their corresponding prePostImageOplog entries. We skip the latter because the prePostImage oplog entries are created as no-ops. We should also filter out corresponding prePostImage oplog entries. Proposed SolutionWe currently have two types of no-op entries that will come through the session catalog migration pipeline. These are either sentinel oplog entries or prePostImage oplog entries. We should:
|
| Comments |
| Comment by Githook User [ 17/May/19 ] | |||||||||||||
|
Author: {'email': 'randolph@10gen.com', 'name': 'Randolph Tan', 'username': 'renctan'}Message: | |||||||||||||
| Comment by Blake Oler [ 14/May/19 ] | |||||||||||||
|
Yes. That is the issue that we discussed today (ticket to follow). This issue exists independent of any changes to the document shard key. renctan | |||||||||||||
| Comment by Randolph Tan [ 10/May/19 ] | |||||||||||||
|
With change shard key project, isn't it possible for the post-image to have different shard key and thus ending up on a different chunk but on the same shard? Or is findAndModify exempt from the in-place update optimization for change shard key? | |||||||||||||
| Comment by Blake Oler [ 09/May/19 ] | |||||||||||||
Approach LGTY? |