This topic describes the major versions available for upgrades in ApsaraDB for MongoDB and how to upgrade the major version of an ApsaraDB for MongoDB instance.
Usage notes
You can only upgrade the major version of an ApsaraDB for MongoDB sharded cluster instance that uses the MongoDB protocol.
Nodes in an instance are upgraded in turn. An instance is automatically restarted two or three times during an upgrade. We recommend that you perform the upgrade during off-peak hours or make sure that your application can automatically reconnect to the instance.
NoteIf your application runs in a production environment, we recommend that you use a connection string URI to connect your application to the instance.
If you use this URI, the primary node is always connected and the read and write operations of your application are not affected by primary/secondary switchover. For more information about how to connect to a database by using a connection string URI, see Connect to a replica set instance or Connect to a sharded cluster instance.
The balancer of a sharded cluster instance is disabled during an upgrade and is enabled after the upgrade.
You cannot downgrade the major version of an instance after you upgrade it.
After you upgrade the major version of an instance, the backup data of an instance that uses an earlier major version cannot be restored to the upgraded instance. You can download the backup file of an instance that uses an earlier major version and restore the backup file to a self-managed database. For more information about how to restore backup data to a self-managed database, see Restore the instance data to a self-managed MongoDB database by using logical backup or Restore the instance data to a self-managed MongoDB database by using physical backup.
MongoDB major versions available for upgrades
You can perform a major version upgrade in the ApsaraDB for MongoDB console. The following table lists the available MongoDB major versions and describes whether the versions are supported in different instance architectures and versions.
Architecture
Category
Current major version
Major version available for upgrade
Standalone instance
General-purpose instance that uses cloud disks
MongoDB 4.0
No new major version is available for upgrade.
General-purpose instance that uses cloud disks
MongoDB 3.4
You cannot upgrade the major version of the instance.
To upgrade the major version of an instance, you can create an instance and replace the old instance with the new instance. For information about how to create a standalone instance, see Create a standalone instance.
Replica set instance
Dedicated instance that uses cloud disks
MongoDB 7.0
No new major version is available for upgrade.
MongoDB 6.0
MongoDB 7.0
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 an 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
MongoDB 3.2
MongoDB 3.0
Sharded cluster instance
Dedicated instance that uses cloud disks
MongoDB 7.0
No new major version is available for upgrade.
MongoDB 6.0
MongoDB 7.0
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 an 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
MongoDB 3.2
MongoDB 3.0
To upgrade the major version of an instance across instance architectures or storage classes, create an instance running a major version to which you want to upgrade and then use Data Transmission Service (DTS) to migrate data from the source instance to the created instance. For more information about how to create an instance, see Create an instance.
For more information about how to migrate data, see the following topics:
Compatibility testing
Before you upgrade the major version of an instance, perform the following steps to complete compatibility testing.
Check and modify the client code based on the major versions that are involved to prevent possible compatibility issues. For more information about how to modify the client code, see ApsaraDB for MongoDB major version upgrade
(Optional) Use the data restoration method to test compatibility between different major versions.
ImportantData restoration incurs additional fees.
Create an instance of the same major version for data restoration. For more information about how to restore data, see Restoration solutions.
Upgrade the major version of the new instance. For more information about the major versions available for upgrades and how to upgrade the major version of an instance, see MongoDB major versions available for upgrades and Upgrade the major version of an instance.
Verify whether the modified client has compatibility issues on the new instance.
If compatibility issues occur, check and modify the client code again based on the error message until no compatibility issues occur.
After compatibility testing is complete, release the new instance.
Procedure
Log on to the ApsaraDB for MongoDB console.
In the left-side navigation pane, click Replica Set Instances or Sharded Cluster Instances.
In the upper-left corner of the page, select the resource group and region to which the desired instance belongs.
Click the ID of the instance or click Manage in the Actions column.
In the Specifications section of the instance details page, click Update Minor Version and select the major version to which you want to upgrade the instance.
In the Update Minor Version message, click OK.