-
Type: Improvement
-
Resolution: Gone away
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
5
-
Storage - Ra 2020-04-20, Storage - Ra 2021-05-17
There's a MongoDB binary downgrade contract with the following requirements (among other caveats):
- FCV must be set to the previous version
- MongoDB must perform a clean shutdown
Right now, MongoDB validates that FCV is set appropriately, however, the clean shutdown part is only enforced by WT. The two ways WT can enforce this are:
- Bumping the log version
- Advancing the release compatibility (with coordination of changing MongoDB compatibility=(release,min,max) calls into WT)
There's a (testing) cost associated with branching a new development version of MongoDB, but delaying the bumping of WT versioning (via either mechanism):
- "implicit" multiversion tests can perform illegal downgrades (typically via crashing the process, or having some restarts in standalone mode). But that illegal downgrade won't be noticed until a formal versioning change is made, which results in a bunch of fallout at once that lands on the wrong team.
- explicit multiversion tests can depend on MongoDB startup failing. Right now, a "bug" where startup works after an illegal downgrade results in a test hang.
- is depended on by
-
SERVER-47219 Correct downgrade_after_rollback_via_refetch to not binary downgrade on crash
- Closed
- is related to
-
SERVER-47538 `runMongoProgram` should omit auth options on multiversion mongod binaries
- Closed
-
SERVER-47540 shard_kill_and_pooling is multiversion incompatible
- Closed
-
SERVER-47542 omit shard_identity_rollback from sharding multiversion suite
- Closed
-
SERVER-56929 Improve error message for improper downgrades resulting in invalid collection options
- Closed
-
SERVER-47425 When 4.2 discovers log version 4 records on startup, continue to write log version 4 records
- Closed