Description

We need a v4.0 upgrade/downgrade page for standalone/repl/sharded clusters

Scope of changes (files that need work and how much)

Upgrade

Prereq

• Upgrade only from 3.6-> 4.0.
• If master-slave repl, convert to repl before upgrade since master-slave is gone.
• Before upgrading to MongoDB 4.0, you must upgrade to pv1.

• If using MongoDB-CR, upgrade to SCRAM before upgrade.
• auth mechanism – scram-sha-256 only for 4.0
• Any driver dependencies?

gotchas DOCS-11532

$isolated/$atomic has already been marked as deprecated, so now it can be marked as removed altogether. The one caveat worth mentioning is the upgrade/downgrade scenario since it's possible to create a partial index with $isolated in 3.4 and allowed to parse in 3.6. The following sequence of steps would crash a mongod on startup:

1. Create partial index with $isolated in 3.4
2. Upgrade to 3.6, everything works fine.
3. Upgrade to 4.0, mongod will fail to start since it doesn't recognize the $isolated option persisted to disk.

Let me know if that makes sense and feel free to follow up if it doesn't!

FCV 4.0

• scram-sha-256
• $convert (and its helpers), the 'format' option to $dateFromString, etc.
• transactions
• generate and store database versions in config.databases on setFCV=4.0

Downgrade

Prereq

• Stored fcv4.0 features (scram-sha-256 credentials, views with agg convert operators) DOCS-11382
• FCV -> 3.6
  *

Impact to other docs outside of this product

None – OpsMgr 4.0 should have its own separate Upgrade ticket.

MVP (work and date?)

Resources (e.g. Scope Docs, Invision)

Engineering Ticket Description:

In order to facilitate the development of 4.0-specific features, a 4.0 value should be added to the featureCompatibility enum and also should be an accepted input to the setFeatureCompatibilityVersion command. Transitions from 3.4 to 4.0 should be explicitly prohibited, as all 3.4-specific code will be removed as part of this project.