All Products
Search
Document Center

ApsaraDB for MongoDB:ApsaraDB for MongoDB major version upgrade

Last Updated:Apr 09, 2024

ApsaraDB for MongoDB supports the upgrades of MongoDB major versions. ApsaraDB for MongoDB supports a variety of instance architectures and versions. Before you upgrade an instance, we recommend that you familiarize yourself with the MongoDB major versions available for upgrade and their compatibility changes.

Major versions available for upgrades

The following table lists the major versions and describes whether the versions are supported in different instance architectures and versions.

Architecture

Instance category

Current major version

Major version available for upgrade

Standalone instance

General-purpose cloud disk instance

MongoDB 4.0

No new major version is available for upgrade.

General-purpose cloud disk instance

MongoDB 3.4

You cannot upgrade the major version of the instance.

To upgrade the major version of an instance, you can create a new instance and replace the old instance with the new instance. For more information about how to create a standalone instance, see Create a standalone instance.

Replica set instance

Dedicated instance that uses cloud disks

MongoDB 6.0

No new major version is available for upgrade.

MongoDB 5.0

MongoDB 6.0

MongoDB 4.4

MongoDB 5.0

  • General-purpose instance that uses local disks

  • Dedicated instance that uses local disks

  • Dedicated host instance

MongoDB 4.2

You cannot upgrade the major version of the instance.

To upgrade the major version of an instance, you can create a new instance and replace the old instance with the new instance. For more information about how to create a replica set instance, see Create a replica set instance.

MongoDB 4.0

MongoDB 4.2

MongoDB 3.4

  • MongoDB 4.0

  • MongoDB 4.2

Sharded cluster instance

Dedicated instance that uses cloud disks

MongoDB 6.0

No new major version is available for upgrade.

MongoDB 5.0

MongoDB 6.0

MongoDB 4.4

MongoDB 5.0

  • General-purpose instance that uses local disks

  • Dedicated instance that uses local disks

  • Dedicated host instance

MongoDB 4.2

You cannot upgrade the major version of the instance.

To upgrade the major version of an instance, you can create a new instance and replace the old instance with the new instance. For more information about how to create a sharded cluster instance, see Create a sharded cluster instance.

MongoDB 4.0

MongoDB 4.2

MongoDB 3.4

  • MongoDB 4.0

  • MongoDB 4.2

Compatibility changes of MongoDB major versions

The following table describes the compatibility changes of MongoDB major versions.

Important
  • When you upgrade the major version for an instance, the instance must be in the Running state. For more information about how to upgrade the major version, see Upgrade the major version of an ApsaraDB for MongoDB instance.

  • Major version downgrade is not supported by instances.

  • Instances that run MongoDB 4.0 support features of MongoDB 3.6. To use features of MongoDB 3.6, upgrade your instance to MongoDB 4.0 or later.

  • The compatibility changes described in this topic involve only MongoDB kernel changes. Changes to instance management features are not described.

Major engine version

Compatibility change

MongoDB 7.0

  • When you upgrade the major version of an instance to MongoDB 7.0, no compatibility issues exist.

  • If you want to downgrade an instance from MongoDB 7.0 to an earlier major version, you must remove the features supported by MongoDB 7.0, such as the following items:

    • Remove all columnar indexes.

    • Unregister the cluster parameters specified by the setClusterParameter command. For more information, see setClusterParameter.

    • Remove all collections that are created with the encryptedFields option.

    • Remove all compound wildcard indexes.

For more information about MongoDB 7.0, see Compatibility Changes in MongoDB 7.0.

MongoDB 6.0

  • If the size of data involved in an aggregation pipeline exceeds 100 MB, the data is written to temporary disk storage by default. To change the default setting, set the global allowDiskUseByDefault parameter to false.

    If you use a version earlier than MongoDB 6.0, you must use the { allowDiskUse: true } syntax to allow data to be written to temporary disk storage.

  • If you use * in the dropIndexes command, you can remove all indexes except the index on the _id field and the last remaining shard key index. For more information, see dropIndexes.

  • The mongo shell is deprecated. Use mongosh instead.

  • Operators such as $explain, $hint, $max, and $maxTimeMS are deprecated.

  • If a time to live (TTL) index has the expireAfterSeconds parameter set to NaN, the system considers this parameter as being set to 0, which causes expired documents to be evicted immediately in some cases.

  • The SCRAM-SHA-1 mechanism is deprecated.

  • The reIndex command and the corresponding reIndex() method are deprecated.

For more information about MongoDB 6.0, see Compatibility Changes in MongoDB 6.0.

MongoDB 5.0

  • The Read Concern level of secondary nodes is changed from available to local. For more information, see Read Concern.

  • The default value of Write Concern is changed from 1 to majority.

  • The db.collection.ensureIndex() method is deprecated. You can use the db.collection.createIndex() method instead.

  • The parameters of the saslStart and saslContinue commands are strictly validated, which may break compatibility with the mgo driver. The saslContinue command contains only the conversationId and payload parameters, whereas mgo has an additional mechanism parameter. For more information, visit mgo.

  • The geoSearch command is deprecated.

For more information about MongoDB 5.0, see Compatibility Changes in MongoDB 5.0.

MongoDB 4.4

  • The force option is unavailable for the compact command. For more information, see compact.

  • The geoSearch command is deprecated. For more information, see geoSearch.

  • You can create indexes on both the primary and secondary databases to reduce the latency caused by index creation. This way, when an index is being created, the secondary database can still access the latest data.

For more information about MongoDB 4.4, see Compatibility Changes in MongoDB 4.4.

MongoDB 4.2

  • The geoNear command is deprecated. Use the $geoNear (aggregation) stage instead. For more information, see geoNear and $geoNear (aggregation).

  • The repairDatabase command is deprecated. For more information, see repairDatabase.

  • The cloneCollection command is deprecated. Use the mongoexport and mongoimport tools instead. For more information, see cloneCollection, mongoexport, and mongoimport.

  • The mapReduce command is deprecated. For more information, see mapReduce.

  • You cannot use the db.collection.dropIndex("*") syntax to remove all indexes that are not on the _id field. You can use the db.collection.dropIndexes() method instead.

  • A unified index creation mechanism across the frontend and backend is in place. An index creation process holds an exclusive lock on a specified collection only at the beginning and end of the process.

    Note
    • When the index creation takes an exclusive lock, the lock cannot be released. This prevents relevant metadata from being modified.

    • The value background of the optional options parameter is deprecated from the db.collection.createIndex(keys, options, commitQuorum) method. If you specify a value for this parameter in the method, ApsaraDB for MongoDB ignores the value.

  • MongoDB implements a stricter validation of the option names for the count command. The command reports an error if you specify an unknown option name. For more information, see count.

  • To use the cursor.min() or cursor.max() method, you must specify the index that you want to use. For more information, see cursor.min() and cursor.max().

  • Drivers that are compatible with MongoDB 4.2 or later enable retryable writes by default. For more information, see Retryable Writes.

  • The group, copydb, and clone commands are deprecated.

For more information about MongoDB 4.2, see Compatibility Changes in MongoDB 4.2.

MongoDB 4.0

  • The reIndex command obtains a global write lock and blocks other operations until indexes are rebuilt. For more information, see reIndex.

  • The copydb and clone commands are deprecated. For more information, see copydb and clone.

For more information about MongoDB 4.0, see Compatibility Changes in MongoDB 4.0.

MongoDB 3.6

MongoDB 3.6 comes between MongoDB 3.4 and MongoDB 4.0. If you want to upgrade an instance from versions earlier than MongoDB 3.6 to MongoDB 4.0 or later, take note of the following items:

  • The aggregate command does not return a single document. Instead, this command returns a cursor. You can specify a batch size for the cursor. For more information about the aggregate command, see aggregate.

  • In MongoDB 3.6 and later, the query for $type: "array" returns documents where the field itself is an array. In the following example, the query returns the documents with _id: 1 and _id: 2. In versions earlier than MongoDB 3.6, the query for $type: "array" returns documents where the field itself is an array that contains at least one element of the array type. In the following example, the query returns only the document with _id: 2.

    Example:

    {"_id":1,"a":[1,2,3]}
    {"_id":2,"a":[1,2,[3,4]]}

    For more information about the $type operator, see $type.

  • The following changes to array ordering are added:

    • The optional sort field is added to the find command to provide the sorted results. For more information about the find command, see find.

    • $sort in the $sort (aggregation) stage has a memory limit of 100 MB. If this limit is exceeded, $sort returns an error. For more information about the $sort(aggregation) stage, see $sort (aggregation).

  • If an update operation involves multiple fields, the fields are added in lexicographical order. For more information, see $set.

  • The values of the ISODate type are returned as strings. Millisecond-level dates are supported, and the letter Z is added at the end of each date.

  • The snapshot query option is deprecated.

For more information about MongoDB 3.6, see Compatibility Changes in MongoDB 3.6.

MongoDB 3.4

  • The group command is deprecated. You can use the $group (aggregation) stage in the aggregate command instead. For more information about the $group (aggregation) stage, see $group (aggregation).

  • The $in expression is used in combination with the upsert option that is set to true to determine whether matching documents exist in an update operation.

    Example:

    db.c.drop()
    db.c.update({a:{$in:[1]}},{$addToSet:{a:2}},{upsert:true}) //This syntax fails to insert a data record into a database that runs MongoDB 3.4 and can insert a data record into a database that runs a major version earlier than MongoDB 3.4. 
    db.c.update({a:{$elemMatch:{$in:[2] }},{$ addToSet:{a:2 },{ upsert:true}) // A data record can be inserted into a database that runs MongoDB 3.4.

    For more information about the update command, see update.

For more information about MongoDB 3.4, see Compatibility Changes in MongoDB 3.4.

Related API operations

Operation

Description

UpgradeDBInstanceEngineVersion

Upgrades the major version of an ApsaraDB for MongoDB instance.