[SERVER-28412] Add flag to allow a query to continue running on a secondary after the primary cleans up orphaned documents Created: 21/Mar/17  Updated: 06/Dec/22  Resolved: 21/Nov/17

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-30593 Add 'available' as a valid read conce... Closed
Related
is related to SERVER-29344 Inform queries on a secondary node wh... Closed
Assigned Teams:
Sharding
Sprint: Sharding 2017-05-29, Sharding 2017-06-19
Participants:

 Description   

After a shard donates a chunk, its primary allows queries that were running before the migration to complete before deleting the underlying data.

The primary does this by tracking the cursors that were active before the migration.

As part of the Safe Secondary Reads project PM-256, the primary will wait for a short buffer period after the active cursors on the primary are exhausted before deleting the underlying data. This is in order to allow active cursors on secondaries to complete before the underlying data is deleted from beneath them.

To guarantee correctness, the primary will drop an entry in the oplog before deleting the underlying data to signal to secondaries that they should cut off any active queries that have not been exhausted even after the buffer period.

However, to preserve the behavior of querying secondaries pre-3.6, we will add a flag, most likely to the readConcern, to allow queries on secondaries to continue even if the underlying data gets deleted.

Drivers may need to do some work to ensure this new readConcern flag is supported.



 Comments   
Comment by Kaloian Manassiev [ 21/Nov/17 ]

With the introduction of the "available" read concern in 3.6, it is now possible to allow queries to specify whether they care about orphaned documents or are willing to see orphans/have documents deleted from underneath them.

Because of this, this ticket is no longer necessary.

Comment by Nathan Myers [ 13/Jun/17 ]

Note that the behavior controlled by this option goes away when we get default snapshot reads, probably 3.8.

Come 3.8, we will need an option to turn off snapshot reads for long-running queries with lax consistency requirements. Probably this option should have a name compatible with that 3.8 usage.

Comment by Nathan Myers [ 06/Jun/17 ]

The name of the new read-concern option is not settled.

Comment by Nathan Myers [ 23/May/17 ]

We have agreed that the option is a field of readConcern, "ignoreChunkMigrations" type bool.

Comment by Nathan Myers [ 18/May/17 ]

Oz has suggested using the existing

allowPartialResults

top-level query option to indicate a query should continue even if the underlying data is deleted. In general, documents deleted by this process moved to another shard, and the query doesn't know what shard it should have been on, or whether the shard it moved to is still up, so the semantics match.

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