[SERVER-31695] Support queries across collection renames Created: 24/Oct/17  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Querying, Replication, Storage
Affects Version/s: 3.6.0-rc0
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Matthew Russotto Assignee: Backlog - Query Execution
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-31267 CollectionCloner fails if collection ... Closed
is depended on by SERVER-37720 Allow active index builds during rena... Blocked
Related
related to SERVER-32089 Support rename collections during ini... Backlog
Tested
tested by SERVER-42606 Create test that initial sync can clo... Closed
Assigned Teams:
Query Execution
Participants:
Linked BF Score: 5

 Description   

When we are querying a collection during initial sync, we do the initial find by UUID. However, subsequent getMore commands are done by name, which is a problem if the collection is renamed. We cannot distinguish a dropped collection from a renamed one because in the getMore has only the old name and thus cannot look up the collection or the cursor.



 Comments   
Comment by David Storch [ 07/Feb/19 ]

Moving back to "Needs Scheduling". Much of the prep-work for this improvement has been completed now that all ClientCursor objects are managed by the global cursor manager. We should re-evaluate its priority.

Comment by Andy Schwerin [ 14/Nov/17 ]

This makes renames kill initial syncs, so I'd like to think about how we can get past this in the future. It might make sense to consider this goal when revisiting the storage apis to support the multi-versioned collection catalog. Please re-triage.

Comment by Geert Bosch [ 03/Nov/17 ]

The bigger issue is that currently client cursors are killed when a collection is renamed. They have to be because the actual Collection object is destructed, and it has the cursor manager which owns the client cursors. Changing this would require major query system work and is definitely out of scope for 3.6. As you indicate there are also issues during yielding which any getMore changed wouldn't fix.

So, instead, when a collection is renamed while it is being cloned, we should simply retry the clone (up to a small constant number of times).

Comment by Eric Milkie [ 25/Oct/17 ]

matthew.russotto spencer could you be more specific about what you would like the new behavior of the getMore command to be?
I see that currently, it checks to make sure that the namespace provided in the command matches the one associated with the cursor, and if they do not match, you get an "Unauthorized" error. So even if we changed the getMore command to take a UUID instead of the collection name, it still would return an error unless more changes to the code were made.
Also, won't the getMore command still fail (and kill its cursor) if the collection is renamed while the getMore command is yielding (but has not yet completed)? Is this behavior acceptable for proper operation of initial sync?

Comment by Spencer Brody (Inactive) [ 24/Oct/17 ]

This would need to happen to allow initial syncs to be resilient to collection drops on the sync source.

Generated at Thu Feb 08 04:27:54 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.