[SERVER-64128] Investigate behavior when query against unsharded collection runs concurrently with shardCollection and moveChunk Created: 02/Mar/22 Updated: 07/Feb/24 |
|
| Status: | Open |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Mihai Andrei | Assignee: | Backlog - Catalog and Routing |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | PM-2144-Milestone-0, PM-3364-Milestone-4, oldshardingemea | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Assigned Teams: |
Catalog and Routing
|
||||||||||||||||||||
| Sprint: | Execution Team 2023-01-09 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
Suppose a query is running against an unsharded collection and a concurrent 'shardCollection' shards the collection and a 'moveChunk' moves a chunk away from the primary shard. When the query yields and reacquires a snapshot of the collection, it's not clear whether there's anything that will protect the query from 'observing' that the collection has not only become sharded, but also some of the data has moved away from the primary shard. This ticket tracks the work to write a test that demonstrates the current behavior of the above scenario. |
| Comments |
| Comment by Jordi Serra Torrens [ 04/Jul/23 ] |
|
The fix should automatically get resolved by the "track unsharded collections" project. |
| Comment by Daniel Gomez Ferro [ 18/Jan/23 ] |
|
We are deferring fixing this issue until we have the infrastructure to properly register acquisition requirements (the new CollectionSnapshot API, |