[SERVER-33872] move atClusterTime back under enableTestCommands parameter Created: 14/Mar/18 Updated: 29/Oct/23 Resolved: 04/Apr/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 3.7.4 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Eric Milkie | Assignee: | Xiangyu Yao (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Storage NYC 2018-04-09 | ||||||||
| Participants: | |||||||||
| Description |
|
atClusterTime needs to avoid reading unique indexes at points in time that were prior to an upgrade of FCV from 3.6 to 4.0. |
| Comments |
| Comment by Eric Milkie [ 04/Apr/18 ] |
|
No, I think it will be a brand new separate Epic just for supporting snapshot reads on secondaries via multi-document transactions. |
| Comment by Tess Avitabile (Inactive) [ 04/Apr/18 ] |
|
Would that be the sharded multi-document transactions epic? Since I think we are planning on closing global snapshot reads in this cycle. |
| Comment by Eric Milkie [ 04/Apr/18 ] |
|
No, and once we do, it should go in the new Epic we're about to create for 4.2 to encompass this work. |
| Comment by Tess Avitabile (Inactive) [ 04/Apr/18 ] |
|
milkie, do we have a ticket for enabling atClusterTime next release? |
| Comment by Githook User [ 04/Apr/18 ] |
|
Author: {'email': 'xiangyu.yao@mongodb.com', 'name': 'Xiangyu Yao', 'username': 'xy24'}Message: |
| Comment by Eric Milkie [ 02/Apr/18 ] |
|
We're going to move atClusterTime back under the protection of enableTestCommands parameter, as it will not be needed in 4.0 production. |
| Comment by Tess Avitabile (Inactive) [ 29/Mar/18 ] |
|
Apologies, I was incorrect. We do not need to worry about what the FCV was at our read timestamp for readConcern level snapshot without atClusterTime. This is because the read timestamp is always chosen at the batch boundary on secondaries, just like for majority reads, so there is no danger of getting an inconsistent view due to a unique index, even if the FCV is 3.6. It is only a danger for atClusterTime, since there is no guarantee that the requested time is at the batch boundary. This ticket can go back to just concerning atClusterTime, and go back down in priority, since global snapshot reads are not planned for 4.0. Thanks, milkie, for clarifying. |
| Comment by Tess Avitabile (Inactive) [ 27/Mar/18 ] |
|
We also need to worry about this when readConcern level snapshot is used without atClusterTime, since even if the current FCV is 4.0, the FCV may have been lower at the majority commit timestamp, which is when we are reading from. The transactions project is planning on gating transactions on FCV 4.0 in |