[SERVER-61731] Retry importing donor collections Created: 24/Nov/21 Updated: 07/Sep/22 Resolved: 06/Jan/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | A. Jesse Jiryu Davis | Assignee: | Suganthi Mani |
| Resolution: | Done | Votes: | 0 |
| Labels: | shard-merge-milestone-1 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Sprint: | Server Serverless 2021-12-13, Server Serverless 2021-12-27, Server Serverless 2022-01-10 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
For multitenant migrations with protocol "shard merge", when the recipient imports donor collections it may fail. The only retryable error we know of is if R's stable timestamp is < the D collections' checkpoint timestamp, aka startApplyingDonorOpTime. We can advance R's majority commit point as necessary ( Question: if there's a WiredTiger error when R tries to import a D collection, how does R know the cause of the error? WT uses EINVAL to express many errors, not just "stable timestamp too old". If R can't determine the cause of the error, it won't know whether to retry. |
| Comments |
| Comment by Suganthi Mani [ 06/Jan/22 ] |
|
We already call import in a writeConflictRetry loop. So, there is nothing to do for this ticket. A test will be added to verify the logic and will be addressed as part of |
| Comment by Suganthi Mani [ 13/Dec/21 ] |
|
In |