[SERVER-36312] Re-enable atClusterTime selection algorithm on mongos Created: 26/Jul/18 Updated: 06/Dec/22 Resolved: 18/Nov/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Jack Mulrow | Assignee: | [DO NOT USE] Backlog - Sharding NYC |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | ShardedTxn:FutureOptimizations, max-triage, pm-564 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||
| Assigned Teams: |
Sharding NYC
|
||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||
| Description |
|
The snapshot transactions' atClusterTime selection algorithm developed as part of the Global Point in Time reads project for 4.0 works as follows:
This algorithm was disabled through In addition, using the majority committed timestamp goes against the performance goals of the speculative snapshot optimization and can also lead to problems on shards with enableMajorityReadConcern=false (where such shards may never provide a snapshot at the selected atClusterTime). Because of this, the algorithm should be changed to use the last applied opTime timestamps of the targeted shards. |
| Comments |
| Comment by Ratika Gandhi [ 18/Nov/21 ] |
|
Closing this. We will reopen this ticket if we hear complaints about stalls from the field. |
| Comment by Kaloian Manassiev [ 14/Jan/19 ] |
|
Due to the multi-version routing table and because document histories are not carried as part of migration, the cluster time selection algorithm in question requires two phases:
The value of this optimization is unclear versus the complexity it introduces and because of this we will not implement it. |
| Comment by Jack Mulrow [ 11/Oct/18 ] |
|
If this work is started after PM-1191 has written integration tests for single replica set sharded transactions with enableReadConcernMajority=false, then it will need to be done in tandem with |
| Comment by Gregory McKeon (Inactive) [ 02/Oct/18 ] |
|
When doing this, we need to make sure we're actually using the routing information from the latest cluster time, which we ended up selecting (rather than the one which was latest at the time the command ran). |