[SERVER-36497] block returning from setFeatureCompatibilityVersion during 4.0 downgrade on all prepared transactions completing Created: 07/Aug/18  Updated: 29/Oct/23  Resolved: 29/Apr/19

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

Type: Task Priority: Major - P3
Reporter: Judah Schvimer Assignee: Vesselina Ratcheva (Inactive)
Resolution: Fixed Votes: 0
Labels: prepare_testing
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
is documented by DOCS-12663 Docs for SERVER-36497: block returnin... Closed
Related
related to SERVER-40793 Allow transactions prepared in 4.2 wi... Closed
related to SERVER-35882 Wait for all prepared transactions to... Closed
related to SERVER-36485 ‘killSessions’ (for one session) and ... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2019-01-28, Repl 2019-02-11, Repl 2019-03-11, Repl 2019-03-25, Repl 2019-04-08, Repl 2019-04-22, Repl 2019-05-06
Participants:
Linked BF Score: 20

 Comments   
Comment by Githook User [ 29/Apr/19 ]

Author:

{'email': 'vesselina.ratcheva@10gen.com', 'name': 'Vesselina Ratcheva', 'username': 'vessy-mongodb'}

Message: SERVER-36497 Test that downgrading FCV to 4.0 waits for prepared transactions to finish

This reverts commit 7dc70f2fd69bd6ad687d7cdc4c0d0c20ac6d9dc5.
Branch: master
https://github.com/mongodb/mongo/commit/7ea05d8684052198c595dee0b9a9cabf652e904d

Comment by Githook User [ 23/Apr/19 ]

Author:

{'email': 'vesselina.ratcheva@10gen.com', 'name': 'Vesselina Ratcheva', 'username': 'vessy-mongodb'}

Message: Revert "SERVER-36497 Test that downgrading FCV to 4.0 waits for prepared transactions to finish"

This reverts commit 6888034d41a3c0fd15950051940cf5e7ede5ba19.
Branch: master
https://github.com/mongodb/mongo/commit/7dc70f2fd69bd6ad687d7cdc4c0d0c20ac6d9dc5

Comment by Githook User [ 22/Apr/19 ]

Author:

{'email': 'vesselina.ratcheva@10gen.com', 'name': 'Vesselina Ratcheva', 'username': 'vessy-mongodb'}

Message: SERVER-36497 Test that downgrading FCV to 4.0 waits for prepared transactions to finish
Branch: master
https://github.com/mongodb/mongo/commit/6888034d41a3c0fd15950051940cf5e7ede5ba19

Comment by Judah Schvimer [ 21/Feb/19 ]

This ticket is just about testing that the behavior is correct today. Moving to "prepare_testing" label as a result.

Comment by Judah Schvimer [ 07/Feb/19 ]

As discussed with siyuan.zhou and tess.avitabile, we'll leave the downgrade behavior as it is today where we abort unprepared transactions so that downgrade blocks other operations for less time.

Comment by Judah Schvimer [ 07/Feb/19 ]

It would speed up downgrade in terms of not blocking acquiring the global S lock. I think having downgrade take longer but do fewer special things would be preferable.

Comment by Siyuan Zhou [ 06/Feb/19 ]

Aborting unprepared transactions will still speed up the downgrade, right? That's a separate issue from "waiting or failing" though.

Comment by Judah Schvimer [ 06/Feb/19 ]

schwerin's suggestion was purely to make the implementation easier. I agree the global S lock will block on prepared transactions to finish. Since that occurs after we transition to "downgrading to 4.0" and stop allowing new prepared transactions, I think this ticket is "remove code for aborting transactions on FCV downgrade" and testing both that and the blocking behavior that is expected to already work.

Comment by Maria van Keulen [ 05/Feb/19 ]

judah.schvimer I am not aware of any unintended consequences for leaving the database in the downgrading state until a successful downgrade occurs; this is a valid state to be in if a downgrade fails. I agree with Tess.

Comment by Siyuan Zhou [ 05/Feb/19 ]

Since we wait for a global S lock in FCV change and we probably still need it for upgrade and downgrade of larger transaction project, it seems we already block on prepared transactions. If Andy's suggestions was to make implementation easier, maybe waiting is actually easier?

Comment by Judah Schvimer [ 05/Feb/19 ]

To clarify, I don't actually see a problem with leaving the database in "downgrading to 4.0". I wasn't sure if there would be any unintended consequences of which I was unaware and wanted to check.

Comment by Tess Avitabile (Inactive) [ 05/Feb/19 ]

I don't see the problem with leaving the database in "downgrading to 4.0". The user still intends to downgrade, so they are likely to keep retrying to set the FCV to 4.0. Remaining in the "downgrading to 4.0" state also will ensure that there are no new prepared transactions, while the remaining prepared transactions resolve. It's very similar to blocking in the setFCV command while waiting for prepared transactions to resolve.

Comment by Judah Schvimer [ 05/Feb/19 ]

siyuan.zhou pointed out that the ordering here between failing the FCV change and downgrading FCV to "downgrading to 4.0" is not atomic and thus needs some thought. We need to fail the downgrade after changing the FCV to "downgrading to 4.0", otherwise a new prepareTransaction command could arrive before changing the FCV, after we decided not to fail. If we fail after changing the FCV to "downgrading to 4.0" , then we leave the database dangling in this downgrading state, which may not be ideal. maria.vankeulen, do you have any ideas or thoughts on this?

Comment by Misha Tyulenev [ 14/Jan/19 ]

Thanks!

Comment by Vesselina Ratcheva (Inactive) [ 14/Jan/19 ]

misha.tyulenev the FCV changes are going to be part of this ticket, so you don't need to make any.

Comment by Misha Tyulenev [ 14/Jan/19 ]

vesselina.ratcheva I'm about to submit for review a fix for SERVER-36485 which will exclude prepared transaction from killing on FCV downgrade. Do I need to make any changes in fCV code?

Comment by Judah Schvimer [ 10/Jan/19 ]

schwerin pointed out that it should be fine to just fail downgrade if there are prepared transactions in progress, rather than block and wait for them to finish. This should be synchronized such that no transactions can become prepared after this check and before we ensure new 'prepareTransaction' commands fail.

We still need to remove code for aborting transactions on FCV downgrade.

Comment by Judah Schvimer [ 24/Sep/18 ]

When complete, please file a ticket to remove any upgrade/downgrade code unnecessary in MongoDB 4.4 with the "4.3 Required" fixVersion and the "replication-42-fcv-checks" label.

Comment by Judah Schvimer [ 08/Aug/18 ]

We also do not need to abort transactions on FCV downgrade anymore.

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