[SERVER-34575] Don't downgrade to 3.6 if startup replication recovery was not run. Created: 19/Apr/18  Updated: 29/Oct/23  Resolved: 04/May/18

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 4.0.0-rc0

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:
Problem/Incident
causes PYTHON-1531 Mongo-orchestration fails on Windows ... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2018-04-23, Repl 2018-05-07
Participants:

 Description   

Consider the following scenario (kudos shane.harvey and MongoOrchestration):

  • Bring up a 4.0 binary on 3.6 data files (or, start a new sharded cluster which starts out in FCV 3.6)
  • Take a first stable checkpoint
  • Upgrade to FCV 4.0
  • Do some writes
  • Crash

Running `./mongod --repair` will not run replication recovery, leaving the FCV value in 3.6. When the node shuts down, it will downgrade to 3.6. This will take an unstable checkpoint, unsetting the WT recovery timestamp. However, none of the "Do some writes" (nor the FCV upgrade) will persist in the checkpoint. Restarting a 4.0 binary will believe the data is consistent at the top of oplog, when it actually needs to recover from the now deleted WT recover timestamp.

A 4.0 binary must not downgrade if replication recovery was not run.



 Comments   
Comment by Githook User [ 04/May/18 ]

Author:

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

Message: SERVER-34575: Only downgrade to 3.6 when oplog was replayed on startup.
Branch: master
https://github.com/mongodb/mongo/commit/c0d6b410b15227051ca96dc54f8d6c1df77630cf

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