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