What you will learn
This is a historical MongoDB 5.0-to-6.0 learning scenario, not a recommendation to deploy those releases today. Use the official version-specific procedure and plan onward upgrades for a real deployment. The scope is a replica set, not a sharded cluster.
Before you begin
Prepare an isolated replica set with a primary and sufficient healthy voting data-bearing members, a verified restore, eligible 5.0 patch versions, FCV 5.0, and compatible OS/CPU/drivers. Download verified target packages. Keep a workload that records acknowledged writes and reconnect behavior running in the rehearsal.
1. Capture topology and FCV
rs.status()
db.version()
db.adminCommand({getParameter: 1, featureCompatibilityVersion: 1})
Inspect all members, replication lag, and voting majority. Stop if a member is unhealthy or initial sync is incomplete. FCV is a cluster feature setting, distinct from the executable version.
2. Upgrade secondaries one at a time
Shut down one eligible secondary cleanly, install the approved target binary using the platform-specific procedure, and restart it with the reviewed configuration. Wait until it returns to SECONDARY and catches up before moving on. Keep the voting majority available.
3. Step down and upgrade the former primary
rs.stepDown()
Run on the primary only after a healthy upgraded secondary can take over. Expect client reconnection and verify retry handling. Confirm the new primary before replacing the former primary’s binaries; wait for it to return as a secondary.
4. Soak before enabling new features
Confirm every member runs the intended binary and the application behaves correctly while FCV is still at the old value.
db.adminCommand({setFeatureCompatibilityVersion: "6.0"})
This command belongs to the historical 6.0 procedure and is a separate decision after the soak period. Later releases can have different confirmation requirements. Do not raise FCV just to clear a dashboard warning.
Example output
The following is an illustrative, normalized lab result, not output captured from a live customer system. Your versions, addresses, timings, and row counts will differ.
// Condensed example from rs.status().members
host1.sample.com:27017 PRIMARY
host2.sample.com:27017 SECONDARY
host3.sample.com:27017 SECONDARY
// Example FCV check after the separately approved historical 6.0 step
{ featureCompatibilityVersion: { version: '6.0' }, ok: 1 }
Member output is condensed from the status document. The former primary can legitimately become a secondary after the election. Check each member’s binary version separately; FCV alone is not the binary inventory.
Verify the result
Every member has the expected build, one primary is elected, and replication is healthy. Verify the application’s actual read/write concerns and retry semantics. Record FCV separately and demonstrate recovery from the backup in the rehearsal.
Troubleshooting
A member that will not start may have incompatible CPU/OS prerequisites or removed configuration options. Election failures require checking majority and electability. Slow catch-up requires I/O/oplog analysis; changing FCV does not solve replication lag.
Recovery and next steps
Before FCV changes, consult the exact binary downgrade restrictions. After new features or incompatible on-disk changes are enabled, restoring the old executable is not a reliable rollback. Retain the verified restore path and the captured write history.