[SERVER-29158] make ShardLocal::_runCommand support read after opTime Created: 12/May/17  Updated: 01/Jun/17  Resolved: 01/Jun/17

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

Type: Task Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Esha Maharishi (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-29107 move shardCollection logic into new _... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2017-05-29, Sharding 2017-06-19
Participants:

 Description   

Unlike

ShardLocal::_runCommand does not do anything to ensure read after opTime.

This ticket is to separate the read after opTime behavior in ShardLocal::_exhaustiveFindOnConfig into an ensureReadAfterOpTime() function and call it in both ShardLocal::_exhaustiveFindOnConfig and ShardLocal::_runCommand.

This is to support moving metadata commands to the config server which use runCommand to do (non-cursor-generating) reads, such as counts.



 Comments   
Comment by Esha Maharishi (Inactive) [ 01/Jun/17 ]

Setting reading from the majority committed snapshot in ShardLocal::_runCommand proves difficult because _runCommand can be used for writes with a local writeConcern during transition to primary. Such writes fail with a WriteConflictException if reading from the majority committed snapshot is set.

So, it isn't really possible to enforce readConcern for non-find reads through ShardLocal without dividing ShardLocal::_runCommand into two functions, one for read commands and one for write commands, which is arduous at the moment.

This ticket was meant to enable SERVER-29107, where we need to do a read (in this case, a count) through ShardLocal::_runCommand for the first time as part of moving shardCollection from mongos to the config server.

Instead of using readAfterOpTime with readConcern majority, I will use readConcern local. This way, the shardCollection command may fail when it doesn't need to (when it sees writes that will get rolled back), but it will never succeed when it shouldn't (if the chunks will become committed, they will definitely be seen by using readConcern local).

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