[SERVER-53542] Extend createOplogFetchingPipelineForResharding() to support atomic applyOps Created: 30/Dec/20 Updated: 06/Dec/22 Resolved: 05/Jun/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Alexander Taskov (Inactive) | Assignee: | [DO NOT USE] Backlog - Sharding NYC |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Sharding NYC
|
||||||||||||
| Participants: | |||||||||||||
| Story Points: | 1 | ||||||||||||
| Description |
|
The ReshardingAggTest::VerifyPipelineAtomicApplyOps() test currently fails since the createOplogFetchingPipelineForResharding() function is looking for prevOpTime and destinedRecipient in each operation being applied. |
| Comments |
| Comment by Max Hirschhorn [ 05/Jun/21 ] |
|
The "TODO |
| Comment by Max Hirschhorn [ 07/Apr/21 ] |
|
The plan is for mongodump to fail if it detects there is a resharding operation in progress. There isn't a need to support atomic applyOps on the collection being resharded. I think the work on this ticket is to remove these commented out lines. |
| Comment by Max Hirschhorn [ 16/Jan/21 ] |
|
The aggregation pipeline for resharding's oplog fetching requires that the "ui" and "destinedRecipient" fields are filled in for the inner ops of an applyOps oplog entry. I believe the work involved on this ticket is to have _applyOps() in apply_ops.cpp fill in the "destinedRecipient" field like it already does with the "ui" field. I'm also now realizing that mongos doesn't support the applyOps command. An atomic applyOps oplog entry would therefore only be generated by an application writing directly to the shard. |