setFeatureCompatibilityVersion¶

On this page

Definition
Syntax
Behavior
Examples

Definition¶

setFeatureCompatibilityVersion¶: Enables or disables the features that persist data incompatible with earlier versions of MongoDB. You can only issue the setFeatureCompatibilityVersion against the admin database.

Syntax¶

The command takes the following form:

db.adminCommand( { setFeatureCompatibilityVersion: <version> } )

The values for the version are:

Version	Description
`"4.4"`	Available on MongoDB 4.4 Deployments Enables the 4.4 features that persist data incompatible with MongoDB 4.2. Enabling these backwards-incompatible features can complicate the downgrade process since you must remove any persisted backwards-incompatible features before you downgrade. It is recommended that after upgrading, you allow your deployment to run without enabling these features for a burn-in period to ensure the likelihood of downgrade is minimal. When you are confident that the likelihood of downgrade is minimal, enable these features.
`"4.2"`	Available on MongoDB 4.2 and 4.4 Deployments Enables the 4.2 features that persist data incompatible with MongoDB 4.0. Enabling these backwards-incompatible features can complicate the downgrade process since you must remove any persisted backwards-incompatible features before you downgrade. It is recommended that after upgrading, you allow your deployment to run without enabling these features for a burn-in period to ensure the likelihood of downgrade is minimal. When you are confident that the likelihood of downgrade is minimal, enable these features. If set on MongoDB 4.4 deployments, Disables the 4.4 features that persist data incompatible with MongoDB 4.2.
`"4.0"`	Available on MongoDB 4.0 and 4.2 Deployments If set on MongoDB 4.0 deployments, Enables the 4.0 features that persist data incompatible with MongoDB 3.6. Enabling these backwards-incompatible features can complicate the downgrade process since you must remove any persisted backwards-incompatible features before you downgrade. It is recommended that after upgrading, you allow your deployment to run without enabling these features for a burn-in period to ensure the likelihood of downgrade is minimal. When you are confident that the likelihood of downgrade is minimal, enable these features. If set on MongoDB 4.2 deployments, Disables the 4.2 features that persist data incompatible with MongoDB 4.0.
`"3.6"`	Available on MongoDB 3.6 and 4.0 Deployments If set on MongoDB 3.6 deployments, Enables the 3.6 features that persist data incompatible with MongoDB 3.4. Enabling these backwards-incompatible features can complicate the downgrade process since you must remove any persisted backwards-incompatible features before you downgrade. It is recommended that after upgrading, you allow your deployment to run without enabling these features for a burn-in period to ensure the likelihood of downgrade is minimal. When you are confident that the likelihood of downgrade is minimal, enable these features. If set on MongoDB 4.0 deployments, Disables the 4.0 features that persist data incompatible with MongoDB 3.6.
`"3.4"`	Available on MongoDB 3.4 and MongoDB 3.6 Deployments If set on MongoDB 3.4 deployments, Enables the 3.4 features that persist data incompatible with MongoDB 3.2. Enabling these backwards-incompatible features can complicate the downgrade process. For details, see Remove 3.4 Incompatible Features. It is recommended that after upgrading, you allow your deployment to run without enabling these features for a burn-in period to ensure the likelihood of downgrade is minimal. When you are confident that the likelihood of downgrade is minimal, enable these features. If set on MongoDB 3.6 deployments, Disables the 3.6 features that persist data incompatible with MongoDB 3.4.
`"3.2"`	Available on MongoDB 3.4 Deployments Disables the 3.4 features that persist data incompatible with MongoDB 3.2.

Note

For a standalone, run the command on the standalone mongod instance.
For a replica set, run the command on the primary. A majority of the data-bearing members must be available.
For a sharded cluster, run the command on a mongos instance.

Behavior¶

Conflicts with Background Operations¶

Certain background operations may prevent execution of setFeatureCompatibilityVersion. Use currentOp to identify any ongoing operations.

Default Values¶

Deployments	`featureCompatibilityVersion`
For new 4.4 deployments	`"4.4"`
For 4.4 deployments upgraded from 4.2	`"4.2"` until you `setFeatureCompatibilityVersion` to `"4.4"`.
For new 4.2 deployments	`"4.2"`
For 4.2 deployments upgraded from 4.0	`"4.0"` until you `setFeatureCompatibilityVersion` to `"4.2"`.
For new 4.0 deployments	`"4.0"`
For 4.0 deployments upgraded from 3.6	`"3.6"` until you `setFeatureCompatibilityVersion` to `"4.0"`.
For new 3.6 deployments	`"3.6"`
For 3.6 deployments upgraded from 3.4	`"3.4"` until you `setFeatureCompatibilityVersion` to `"3.6"`.
For new 3.4 deployments	`"3.4"`
For 3.4 deployments upgraded from 3.2	`"3.2"` until you `setFeatureCompatibilityVersion` to `"3.4"`.

Idempotency¶

This command must perform writes to an internal system collection. If for any reason the command does not complete successfully, you can safely retry the command as the operation is idempotent.

Examples¶

View FeatureCompatibilityVersion¶

To view the featureCompatibilityVersion for a mongod instance, run the following command on a mongod instance:

Note

The operation is undefined on the mongos instances. For a sharded cluster that has access control enabled, to run the command against a member of the shard replica set, you must connect to the member as a shard local user.

copy

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

In the results document, the format of the featureCompatibilityVersion depends on the MongoDB version. Click on the tab for the appropriate MongoDB version.

For MongoDB 3.6 or greater
For MongoDB 3.4

For MongoDB 3.6 or greater mongod instances:

If the deployment has the default featureCompatibilityVersion, or if the setFeatureCompatibilityVersion command has run successfully against the deployment, the featureCompatibilityVersion has the form:
copy
```
"featureCompatibilityVersion" : {
   "version" : <version>
}
```
If the mongod is in a partially upgraded or downgraded state, the featureCompatibilityVersion has the following form:
copy
```
"featureCompatibilityVersion" : {
   "version" : <version> ,
   "targetVersion" : <target version>
}
```
For instance, if a sharded cluster has a shard replica set that is read only when you run setFeatureCompatibilityVersion command against the mongos, the command will fail, and the featureCompatibilityVersion of the config servers will include the targetVersion field.

Or if a replica set becomes read only while setFeatureCompatibilityVersion is running, the command will fail, and the featureCompatibilityVersion of the replica set will include the targetVersion field as well.

For MongoDB 3.4 mongod instances:

copy

"featureCompatibilityVersion" : <version>

Set Feature Compatibility Version on MongoDB 4.4 Deployments¶

Enable 4.4 Backwards Incompatible Features
Disable 4.4 Backwards Incompatible Features

To enable the 4.4 features that persist data incompatible with MongoDB 4.2, set the feature compatibility to "4.4" on the MongoDB 4.4 deployment:

Note

Run the setFeatureCompatibilityVersion command against the admin database.

For a standalone, run the command on the standalone mongod instance.
For a replica set, run the command on the primary. A majority of the data-bearing members must be available.
For a sharded cluster, run the command on a mongos instance.

copy

db.adminCommand( { setFeatureCompatibilityVersion: "4.4" } )

To disable the 4.4 features that persist data incompatible with MongoDB 4.2, set the feature compatibility to "4.2" on the MongoDB 4.4 deployment:

Note

Run the setFeatureCompatibilityVersion command against the admin database.

For a standalone, run the command on the standalone mongod instance.
For a replica set, run the command on the primary. A majority of the data-bearing members must be available.
For a sharded cluster, run the command on a mongos instance.
"4.2" featureCompatibilityVersion is supported on MongoDB 4.2 and MongoDB 4.4 deployments only.

copy

db.adminCommand( { setFeatureCompatibilityVersion: "4.2" } )

If run as part of the downgrade process from MongoDB 4.4 to MongoDB 4.2, you must also remove all persisted features that are incompatible with 4.2. See the appropriate downgrade procedures.

Set Feature Compatibility Version on MongoDB 4.2 Deployments¶

Enable 4.2 Backwards Incompatible Features
Disable 4.2 Backwards Incompatible Features

To enable the 4.2 features that persist data incompatible with MongoDB 4.0, set the feature compatibility to "4.2" on the MongoDB 4.2 deployment:

Note

Run the setFeatureCompatibilityVersion command against the admin database.

For a standalone, run the command on the standalone mongod instance.
For a replica set, run the command on the primary. A majority of the data-bearing members must be available.
For a sharded cluster, run the command on a mongos instance.

copy

db.adminCommand( { setFeatureCompatibilityVersion: "4.2" } )

To disable the 4.2 features that persist data incompatible with MongoDB 4.0, set the feature compatibility to "4.0" on the MongoDB 4.2 deployment:

Note

Run the setFeatureCompatibilityVersion command against the admin database.

For a standalone, run the command on the standalone mongod instance.
For a replica set, run the command on the primary. A majority of the data-bearing members must be available.
For a sharded cluster, run the command on a mongos instance.
"4.0" featureCompatibilityVersion is supported on MongoDB 4.0 and MongoDB 4.2 deployments only.

copy

db.adminCommand( { setFeatureCompatibilityVersion: "4.0" } )

If run as part of the downgrade process from MongoDB 4.2 to MongoDB 4.0, you must also remove all persisted features that are incompatible with 4.0. See the appropriate downgrade procedures.

Set Feature Compatibility Version on MongoDB 4.0 Deployments¶

Enable 4.0 Backwards Incompatible Features
Disable 4.0 Backwards Incompatible Features

To enable the 4.0 features that persist data incompatible with MongoDB 3.6, set the feature compatibility to "4.0" on the MongoDB 4.0 deployment:

Note

Run the setFeatureCompatibilityVersion command against the admin database.

For a standalone, run the command on the standalone mongod instance.
For a replica set, run the command on the primary. A majority of the data-bearing members must be available.
For a sharded cluster, run the command on a mongos instance.

copy

db.adminCommand( { setFeatureCompatibilityVersion: "4.0" } )

To disable the 4.0 features that persist data incompatible with MongoDB 3.6, set the feature compatibility to "3.6" on the MongoDB 4.0 deployment:

Note

Run the setFeatureCompatibilityVersion command against the admin database.

For a standalone, run the command on the standalone mongod instance.
For a replica set, run the command on the primary. A majority of the data-bearing members must be available.
For a sharded cluster, run the command on a mongos instance.
"3.6" featureCompatibilityVersion is supported on MongoDB 3.6 and MongoDB 4.0 Deployments Only.

copy

db.adminCommand( { setFeatureCompatibilityVersion: "3.6" } )

If run as part of the downgrade process from MongoDB 4.0 to MongoDB 3.6, you must also remove all persisted features that are incompatible with 3.6. See the appropriate downgrade procedures.

Set Feature Compatibility Version on MongoDB 3.6 Deployments¶

Enable 3.6 Backwards Incompatible Features
Disable 3.6 Backwards Incompatible Features

To enable the 3.6 features that persist data incompatible with MongoDB 3.4, set the feature compatibility to "3.6" on the MongoDB 3.6 deployment:

Note

Run the setFeatureCompatibilityVersion command against the admin database.

For a standalone, run the command on the standalone mongod instance.
For a replica set, run the command on the primary. A majority of the data-bearing members must be available.
For a sharded cluster, run the command on a mongos instance.

copy

db.adminCommand( { setFeatureCompatibilityVersion: "3.6" } )

To disable the 3.6 features that persist data incompatible with MongoDB 3.4, set the feature compatibility to "3.4" on the MongoDB 3.6 deployment:

Note

Run the setFeatureCompatibilityVersion command against the admin database.

For a standalone, run the command on the standalone mongod instance.
For a replica set, run the command on the primary. A majority of the data-bearing members must be available.
For a sharded cluster, run the command on a mongos instance.
"3.4" featureCompatibilityVersion is supported on MongoDB 3.6 and MongoDB 3.4 Deployments Only.

copy

db.adminCommand( { setFeatureCompatibilityVersion: "3.4" } )

If run as part of the downgrade process from MongoDB 3.6 to MongoDB 3.4, you must also remove all persisted features that are incompatible with 3.4. See the appropriate downgrade procedures.

Set Feature Compatibility Version on MongoDB 3.4 Deployments¶

Enable 3.4 Backwards Incompatible Features
Disable 3.4 Backwards Incompatible Features

Warning

Enabling these backwards-incompatible features can complicate the downgrade process. For details, see Remove 3.4 Incompatible Features.

It is recommended that after upgrading, you allow your deployment to run without enabling these features for a burn-in period to ensure the likelihood of downgrade is minimal. When you are confident that the likelihood of downgrade is minimal, enable these features.

To enable the 3.4 features that are backward incompatible, set the feature compatibility to "3.4" on the MongoDB 3.4 deployment:

Note

Run the setFeatureCompatibilityVersion command against the admin database.

For a standalone, run the command on the standalone mongod instance.
For a replica set, run the command on the primary. A majority of the data-bearing members must be available.
For a sharded cluster, run the command on a mongos instance.

copy

db.adminCommand( { setFeatureCompatibilityVersion: "3.4" } )

To disable the 3.4 backwards-incompatible features, set the feature compatibility to "3.2" on the MongoDB 3.4 deployment:

Note

Run the setFeatureCompatibilityVersion command against the admin database.

For a standalone, run the command on the standalone mongod instance.
For a replica set, run the command on the primary. A majority of the data-bearing members must be available.
For a sharded cluster, run the command on a mongos instance.
"3.2" featureCompatibilityVersion is supported on MongoDB 3.4 and MongoDB 3.2 Deployments Only.

copy

db.adminCommand( { setFeatureCompatibilityVersion: "3.2" } )

Setting the featureCompatibilityVersion to "3.2" disables the use of these features but does not remove existing usage of these features.

If performed as part of a downgrade to 3.2 procedure, you must also manually remove the existing usage before downgrading the binaries. For details, see Remove 3.4 Incompatible Features.

← renameCollection setIndexCommitQuorum →