[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: |
|
||||||||||||||||
| 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
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. |