[SERVER-47219] Correct downgrade_after_rollback_via_refetch to not binary downgrade on crash Created: 01/Apr/20  Updated: 29/Oct/23  Resolved: 28/Apr/20

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 4.4.0-rc2, 4.7.0

Type: Bug Priority: Major - P3
Reporter: Daniel Gottlieb (Inactive) Assignee: Daniel Gottlieb (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
depends on SERVER-47538 `runMongoProgram` should omit auth op... Closed
depends on WT-5964 4.2 unable to open properly downgrade... Closed
depends on WT-5934 Stop validating timestamps read from ... Closed
depends on WT-6011 Bump the compatibility version for Mo... Closed
Related
related to SERVER-45010 Clean shutdown after rollbackViaRefet... Closed
related to SERVER-47126 Clean dbpath when downgrading arbiter... Closed
related to SERVER-46714 dbtest StorageTimestampTests suite re... Closed
related to SERVER-38925 Rollback via refetch can cause _id du... Closed
is related to SERVER-48082 WT clean shutdown should do a quick e... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.4
Sprint: Execution Team 2020-04-06, Execution Team 2020-05-04
Participants:
Linked BF Score: 50

 Comments   
Comment by Githook User [ 28/Apr/20 ]

Author:

{'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com', 'username': 'dgottlieb'}

Message: SERVER-47219: Leave a paper trail for when to forward port 0b9f132bd60875a276f3cdaa53efe5e5bb5d1f0b
Branch: master
https://github.com/mongodb/mongo/commit/417e36920af24736f7ebdd107d9b3258290b5393

Comment by Alex Cameron (Inactive) [ 23/Apr/20 ]

As we discussed, the solution here is going to be to disable this test until majority reads are removed. Assigning back to execution team backlog.

Comment by Githook User [ 17/Apr/20 ]

Author:

{'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com', 'username': 'dgottlieb'}

Message: SERVER-47219: Ensure downgrade_after_rollback_via_refetch only downgrades after clean shutdown.
Branch: v4.4
https://github.com/mongodb/mongo/commit/0b9f132bd60875a276f3cdaa53efe5e5bb5d1f0b

Comment by Daniel Gottlieb (Inactive) [ 17/Apr/20 ]

kelsey.schubert Yep, it's going in now.

Comment by Kelsey Schubert [ 16/Apr/20 ]

Can we push to 4.4 now and forward port after WT-6011 is in master? I'd like to get the 4.4 branch green.

Comment by Daniel Gottlieb (Inactive) [ 15/Apr/20 ]

I'm marking this as depends on WT-6011, because the patch can only be pushed to the 4.4 branch. Pushing the patch to master causes a hang because 4.5 and 4.4 are indistinguishable at startup.

Comment by Luke Chen [ 08/Apr/20 ]

daniel.gottlieb WT-5934 had been vendor-ed into mongo v4.2 branch. Hope that unblocks SERVER-47219.

Comment by Daniel Gottlieb (Inactive) [ 02/Apr/20 ]

tess.avitabile and I talked and our approach to fix this was to perform a clean shutdown. A clean shutdown though falls into this clause that effectively circumvents the downgrade process. After some poking, we concluded that startup replication recovery is in fact resilient to idempotency problems due to potentially re-applying oplog entries. With that, we're confident that performing an untimestamped checkpoint[1] (given the appropriate minValid/appliedThrough values) is sufficient for allowing the data to downgrade correctly to 4.2.

However, the current tip of 4.2 is unable to open the datafiles because of a bug described in WT-5964.

[1] There's some considerations about when this checkpoint is taken depending on how much code we want to change. That will be decided when the ticket is unblocked.

Generated at Thu Feb 08 05:13:36 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.