[SERVER-47952] If a snapshot read targets one shard, let the shard choose the timestamp Created: 05/May/20 Updated: 11/Jun/20 Resolved: 11/Jun/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | A. Jesse Jiryu Davis | Assignee: | A. Jesse Jiryu Davis |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Sprint: | Repl 2020-06-01, Repl 2020-06-15 | ||||||||||||
| Participants: | |||||||||||||
| Linked BF Score: | 25 | ||||||||||||
| Description |
|
Normally, a snapshot read outside a multi-document transaction will target multiple shards, and mongos selects a timestamp for readConcern.atClusterTime. If only a single shard is targeted, snapshot timestamp selection can be deferred to the mongod. Thus, sending readConcern: {level: "snapshot"} is sufficient. Implement this optimization in mongos. Capture the atClusterTime returned by the shard and store it on the cursor (for find/aggregate) and return it to the client. |
| Comments |
| Comment by Githook User [ 11/Jun/20 ] |
|
Author: {'name': 'A. Jesse Jiryu Davis', 'email': 'jesse@mongodb.com', 'username': 'ajdavis'}Message: Revert " This reverts commit 219dadadf97345a4cceab50f04e87b361a749c6c. |
| Comment by A. Jesse Jiryu Davis [ 11/Jun/20 ] |
|
Decided this optimization made the code too complex and its behavior unpredictable, for dubious benefit. Instead, mongos will always choose the latest timestamp it knows when it begins a snapshot read. Shards wait for that timestamp to be majority committed before they respond. |
| Comment by A. Jesse Jiryu Davis [ 09/Jun/20 ] |
|
This ticket has been much more difficult than expected. We'll reevaluate on Thursday whether to continue, or cancel the ticket and revert the changes so far. |
| Comment by A. Jesse Jiryu Davis [ 05/Jun/20 ] |
|
"find" is done, still must do "aggregate" and "distinct" |
| Comment by Githook User [ 05/Jun/20 ] |
|
Author: {'name': 'A. Jesse Jiryu Davis', 'email': 'jesse@mongodb.com', 'username': 'ajdavis'}Message: |
| Comment by A. Jesse Jiryu Davis [ 03/Jun/20 ] |
|
The first attempt wasn't commented by the git bot, here it is: https://github.com/mongodb/mongo/commit/41cff016562656589bd3a3c114d6dfb31dd3271f |
| Comment by Githook User [ 02/Jun/20 ] |
|
Author: {'name': 'A. Jesse Jiryu Davis', 'email': 'jesse@mongodb.com', 'username': 'ajdavis'}Message: Revert " This reverts commit 41cff016562656589bd3a3c114d6dfb31dd3271f. |