[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:
Depends
depends on SERVER-36659 Allow shard to choose global read tim... Closed
Problem/Incident
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 "SERVER-47952 Shard selects timestamp for one-shard snapshot find"

This reverts commit 219dadadf97345a4cceab50f04e87b361a749c6c.
Branch: master
https://github.com/mongodb/mongo/commit/e485c1a8011d85682cb8dafa87ab92b9c23daa66

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: SERVER-47952 Shard selects timestamp for one-shard snapshot find
Branch: master
https://github.com/mongodb/mongo/commit/219dadadf97345a4cceab50f04e87b361a749c6c

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 "SERVER-47952 Shard selects timestamp for one-shard snapshot find"

This reverts commit 41cff016562656589bd3a3c114d6dfb31dd3271f.
Branch: master
https://github.com/mongodb/mongo/commit/88b6242dbcb7815a89fb84cdbce260f18015db92

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