- Reference >
- Database Commands >
- Administration Commands >
- setFeatureCompatibilityVersion
setFeatureCompatibilityVersion¶
On this page
Definition¶
-
setFeatureCompatibilityVersion
¶ Enables or disables the features that persist data incompatible with earlier versions of MongoDB. You can only issue the
setFeatureCompatibilityVersion
against theadmin
database.The command takes the following form:
The values for the
version
are:Version Description "4.2"
Available on MongoDB 4.2 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.
"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.
The optional
writeConcern
specifies the write concern wtimeout value in milliseconds:- The time period that the primary waits for acknowledgment from the majority of the replica set members. If the acknowledgment is not received in the time period, the operation fails.
- Default is
60000
milliseconds. Use a longer time period if the secondary members of the replica set have a delay that exceeds the wtimeout default.
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.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.
Feature Compatibility in Arbiters¶
Arbiters do not replicate the admin.system.version
collection.
Because of this, arbiters always have a Feature Compatibility Version equal
to the downgrade version of the binary, regardless of the FCV value of the
replica set.
For example, an arbiter in a MongoDB 4.2 cluster, has an FCV value of 4.0.
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.
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 thesetFeatureCompatibilityVersion
command has run successfully against the deployment, thefeatureCompatibilityVersion
has the form:If the
mongod
is in a partially upgraded or downgraded state, thefeatureCompatibilityVersion
has the following form:For instance, if a sharded cluster has a shard replica set that is read only when you run
setFeatureCompatibilityVersion
command against themongos
, the command will fail, and thefeatureCompatibilityVersion
of the config servers will include thetargetVersion
field.Or if a replica set becomes read only while
setFeatureCompatibilityVersion
is running, the command will fail, and thefeatureCompatibilityVersion
of the replica set will include thetargetVersion
field as well.
For MongoDB 3.4 mongod
instances:
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.
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.
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.
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.
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.
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.
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.
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.
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.
Set Write Concern Timeout¶
The following example sets the optional write concern wtimeout field to 5000 (5 seconds).
Note
Run the setFeatureCompatibilityVersion
command against
the admin
database.