[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:
Depends
depends on SERVER-69445 Implement the CollectionSnapshot(s) i... Closed
is depended on by SERVER-64049 Investigate read behavior of unsharde... Closed
Related
is related to SERVER-78071 A targeted query with a concurrent yi... Open
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, SERVER-69445), otherwise we'd spend too much effort to throw it away soon.

Generated at Thu Feb 08 05:59:34 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.