3.4 > 3.6 Downgrade

40 views

Skip to first unread message

Richard Fletcher

unread,

Jan 17, 2018, 2:57:13 PM1/17/18

to mongodb-user

Hi,

I am currently running a downgrade from 3.6 > 3.4. I am running the command db.adminCommand({setFeatureCompatibilityVersion: "3.4"}) as part of the process.

Can anyone advise how long this process is likely to take? It has been running for 2 hours currently.

Thanks

Kevin Adistambha

unread,

Jan 21, 2018, 7:36:17 PM1/21/18

to mongodb-user

Hi Richard

One possible reason why the command appear to hang for long period of time is that the command cannot satisfy the write concern, and is currently waiting for a secondary to catch up.

If run on a replica set, the setFeatureCompatibilityVersion command must propagate to the majority of voting nodes so that it cannot be rolled back; as mentioned in the setFeatureCompatibilityVersion page: “For a replica set, run the command on the primary. A majority of the data-bearing members must be available.”

Certain replica set configuration can trigger this behaviour, such as having a delayed secondary or a network issue. You can check the output of FeatureCompatibilityVersion and see if it contains targetVersion, which means that it’s in the process of running this command.

If this is still an issue, could you clarify the topology of your MongoDB deployment, the output of rs.status() and rs.conf() if running a replica set, and the output of db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )