[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:
Related
related to SERVER-35643 Allow atClusterTime when enableTestCo... Closed
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.
We can achieve this by either disabling atClusterTime in mongod 4.0, or by recording the optime of the completion of the last FCV upgrade to 4.0 and using that optime as a floor on the allowed atClusterTime parameters.



 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: SERVER-33872 atClusterTime is only allowed for testing
Branch: master
https://github.com/mongodb/mongo/commit/4c42865f840749592ce16f4e0858b09522e6a74d

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 SERVER-33240, but they are counting on local snapshot reads to cover the case when FCV was not 4.0 at the majority commit timestamp. Is it possible to prioritize this work and expand it to cover readConcern level snapshot without atClusterTime?

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