[SERVER-40793] Allow transactions prepared in 4.2 with the multiple oplog transaction format commit or abort with the same format while downgrading to 4.0 Created: 23/Apr/19  Updated: 23/Sep/19  Resolved: 13/May/19

Status: Closed
Project: Core Server
Component/s: Replication, Upgrade/Downgrade
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Vesselina Ratcheva (Inactive) Assignee: Jason Chan
Resolution: Duplicate Votes: 0
Labels: bigtxns_upgrade_downgrade, todo_in_code
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-40919 Remove usages of the stmtId field for... Closed
Related
related to SERVER-42528 Complete TODO listed in SERVER-40793 Closed
related to SERVER-42535 Complete TODO listed in SERVER-40793 Closed
related to SERVER-43471 Complete TODO listed in SERVER-40793 Closed
is related to SERVER-36497 block returning from setFeatureCompat... Closed
Operating System: ALL
Sprint: Repl 2019-05-20
Participants:
Linked BF Score: 20

 Description   

We must allow committing and aborting prepared transactions while downgrading to 4.0 because they block the completion of that downgrade. We already do this but we also have to make sure that if they were prepared while using the multiple oplog entries transaction format, the corresponding commit or abort respects that format's logic for assigning the statementId for the commit or abort oplog entry. What this means is that we should be assigning the next consecutive statementId not just in the "fully upgraded to 4.2" case, but also in the "downgrading to 4.0" case. If we don't do this, then the commit or abort entries written mid-downgrade will receive a hard-coded stmtId of 1, which will have already been assigned at or by the time we prepared the transaction in 4.2 while using the new format. We should not be using the same stmtIds twice, so we should make the above fix to prevent that from happening. We should also investigate if there are other problems besides statementIds in this downgrade scenario.

As part of this ticket, we should also investigate whether the logic to check FCV here in OpObserverImpl::onPreparedTransactionCommit can be cleaned up or refactored, as we already have logic for disallowing prepared transactions in 4.0.



 Comments   
Comment by Siyuan Zhou [ 22/May/19 ]

SERVER-40919 removed the redundant FCV check that caused this problem initially.

Comment by Jason Chan [ 13/May/19 ]

vesselina.ratcheva 

Since this ticket stemmed from the issue of incompatible stmtIds, I'm closing this ticket in favor of SERVER-40919. This work should no longer be necessary once we remove stmtIds from transaction oplog entries.

Comment by Vesselina Ratcheva (Inactive) [ 02/May/19 ]

The last commit for SERVER-36497 left TODOs here and here.

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