Upgrading to a new Major Version
When a major version of a database is at its end of life (EOL), upgrade to the next available major version.
Prepare to run on, and then migrate to, the latest version before the EOL date. For more information, see Versioning Policy.
Rolling back versions is not supported.
Upgrade to the latest version of MongoDB available to Databases for MongoDB. Find the latest version from the catalog page, from the Cloud Databases CLI plug-in command ibmcloud cdb deployables-show, or from the Cloud Databases API /deployables endpoint.
Upgrading is handled by restoring a backup of your data into a new deployment. Restoring from a backup has various advantages:
- The original database stays running and production work can be uninterrupted.
- You can test the new database out of production and act on any application incompatibilities.
- The entire process can be rerun at any point.
- A fresh restoration reduces the likelihood that unneeded artifacts of the older version of the database are carried over to the new database.
Upgrade paths
| Current Version | Major Version Upgrade Path |
|---|---|
| MongoDB 4.4 | -> MongoDB 4.4 -> 5.0 |
| MongoDB 5.0 | -> MongoDB 5.0 -> 6.0 |
| MongoDB 6.0 | -> Latest version |
Upgrading in the UI
You can upgrade to a new version by restoring a backup from the Backups tab of your Deployment Overview. Click Restore on a backup to bring up a dialog box where you can change some options for the new deployment. One of them is the database version, which is auto-populated with the versions available for you to upgrade to. Select a version and click Restore to start the provision and restore process.
Upgrading through the CLI
When you upgrade and restore from backup through the IBM Cloud CLI, use the provisioning command from the resource controller.
ibmcloud resource service-instance-create <service-name> <service-id> <service-plan-id> <region>
The parameters service-name, service-id, service-plan-id, and region are all required. You also supply the -p with the version and backup ID parameters in a JSON object. The new
deployment is automatically sized with the same disk and memory as the source deployment at the time of the backup.
ibmcloud resource service-instance-create example-upgrade databases-for-mongodb standard us-south \
-p \ '{
"backup_id": "crn:v1:bluemix:public:databases-for-mongodb:us-south:a/54e8ffe85dcedf470db5b5ee6ac4a8d8:1b8f53db-fc2d-4e24-8470-f82b15c71717:backup:06392e97-df90-46d8-98e8-cb67e9e0a8e6",
"version":"5.0"
}'
Upgrading through the API
Similar to provisioning through the API, you need to complete the necessary steps to use the resource controller API before you can use it to upgrade from a backup. Then, send the API a POST request. The parameters name, target, resource_group, and resource_plan_id are all required. You also supply the
version and backup ID. The new deployment has the same memory and disk allocation as the source deployment at the time of the backup.
curl -X POST \
https://resource-controller.cloud.ibm.com/v2/resource_instances \
-H 'Authorization: Bearer <>' \
-H 'Content-Type: application/json' \
-d '{
"name": "my-instance",
"target": "bluemix-us-south",
"resource_group": "5g9f447903254bb58972a2f3f5a4c711",
"resource_plan_id": "databases-for-mongodb-standard",
"backup_id": "crn:v1:bluemix:public:databases-for-mongodb:us-south:a/54e8ffe85dcedf470db5b5ee6ac4a8d8:1b8f53db-fc2d-4e24-8470-f82b15c71717:backup:06392e97-df90-46d8-98e8-cb67e9e0a8e6",
"version":"5.0"
}'