[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: |
|
||||||||||||||||||||||||
| 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: This reverts commit 7dc70f2fd69bd6ad687d7cdc4c0d0c20ac6d9dc5. |
| Comment by Githook User [ 23/Apr/19 ] |
|
Author: {'email': 'vesselina.ratcheva@10gen.com', 'name': 'Vesselina Ratcheva', 'username': 'vessy-mongodb'}Message: Revert " This reverts commit 6888034d41a3c0fd15950051940cf5e7ede5ba19. |
| Comment by Githook User [ 22/Apr/19 ] |
|
Author: {'email': 'vesselina.ratcheva@10gen.com', 'name': 'Vesselina Ratcheva', 'username': 'vessy-mongodb'}Message: |
| 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 |
| 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. |