[SERVER-35882] Wait for all prepared transactions to complete and clear the transaction table, on fCV downgrade Created: 28/Jun/18  Updated: 07/Aug/18  Resolved: 07/Aug/18

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

Type: Task Priority: Major - P3
Reporter: Gregory McKeon (Inactive) Assignee: Judah Schvimer
Resolution: Duplicate Votes: 0
Labels: prepare_upgrade_downgrade
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-35881 Gate prepare on featureCompatibilityV... Closed
Related
is related to SERVER-36497 block returning from setFeatureCompat... Closed
is related to SERVER-36498 Remove 'config.transactions' entries ... Closed
Participants:

 Comments   
Comment by Judah Schvimer [ 07/Aug/18 ]

This ticket has been split up into SERVER-35881, SERVER-36497, and SERVER-36498.

Comment by Judah Schvimer [ 02/Jul/18 ]

SERVER-35881 should take care of "don't accept new prepares".

Comment by Esha Maharishi (Inactive) [ 02/Jul/18 ]

That sounds good to me.

The downgrading state sounds like a better alternative to a critical section, and serves the same purpose.

Comment by Judah Schvimer [ 02/Jul/18 ]

I think you're right. I think in "downgrading to fCV 4.0" we stop allowing new transactions to be prepared, voting abort or returning an equivalent error, but we keep letting prepared transactions commit or abort. We then block on all prepared transactions to commit or abort. Once there are no outstanding prepared transactions we can complete the downgrade. What do you think?

Comment by Esha Maharishi (Inactive) [ 02/Jul/18 ]

Why is it safe to do this?

It seems like the transaction commit can race (across the cluster) with setFCV.

Why not block setFCV until all pre-existing transactions have completed, the way we will do for migrations?

This may require some kind of setFCV critical section (perhaps the migration critical section can be reused).

CC jack.mulrow

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