升级到新的主要版本

Databases for MongoDB 提供两种不同的升级路径：

就地升级到新的主要版本（目前支持 MongoDB 标准计划）。
从备份恢复（支持 MongoDB 标准计划和 MongoDB 企业计划）。

就地主要版本升级

就地主要版本升级可以将部署升级到下一个新的主要版本，无需将备份恢复到新的部署中。这种方法可以保持相同的连接字符串，无需重新配置部署。但是，如果新的主要版本需要对应用程序进行调整，则必须加以解决。

在就地主要版本升级窗口（包括备份）期间，部署会被设置为 setUserWriteBlockMode，只允许读操作，不允许对部署进行写操作，以确保安全升级。部署的主要版本升级完成后，将立即删除 writeBlockMode 将被删除。

在执行就地主要版本升级时，有两种选择：

带备份的就地主要版本升级：此路径在执行实际升级前创建备份，提供额外的安全保障。
无备份的就地主要版本升级：该选项在不创建备份的情况下进行升级。如果就地升级不成功，则需要将部署从最新备份还原到新部署中。

不建议在没有备份的情况下就地升级。如果升级在任何阶段失败，都可能导致数据丢失，因为没有即时备份可用于恢复。

准备工作

在启动升级程序之前，请考虑以下几个方面。

升级前，您的部署必须处于健康状态。
您的部署必须至少有 2 GB 可用磁盘空间。
您的部署中必须没有用户拥有 bypassWriteBlockingMode.
您只能升级到下一个主要版本，而不是指定您选择的版本。
每个主要版本都包含一些可能无法向后兼容以前版本的功能。查看数据库供应商提供的发行说明，了解可能影响应用程序的任何更改。
不支持将部署降级到以前的版本。
就地主要版本升级一旦开始就不能取消。

在 UI 中升级

创建一个新的 Databases for MongoDB 来测试升级过程。
从版本相同的现有部署中恢复备份，创建部署。
将暂存应用程序指向测试部署。
更新暂存应用程序，使其指向测试部署。确认测试应用程序可以成功连接到暂存部署，并且应用程序的运行符合预期。对暂存环境进行所需的性能和运行测试。
单击“概览”页面上的“升级主要版本”按钮，升级测试部署的主要版本。
升级过程完成后，数据库将进入“只读”模式。注意升级需要多长时间才能完成，这样就可以使用升级过期设置将升级控制在维护窗口内。
确认您的暂存应用程序可与新数据库版本配合使用。
如果应用程序正常运行，这一步将确认升级生产数据库是安全的。
将生产数据库部署升级到新版本。
一旦确认使用新版本的数据库可以正常运行应用程序，就可以返回管理控制台，开始升级生产部署。在 “概览”页面的“部署详情”部分，单击“升级主要版本”按钮并按步骤操作。

就地升级程序一旦启动，就无法停止或回滚。因此，万一发生错误，您的数据库部署可能无法恢复。因此，请创建一个备份，然后将其还原到新的部署中。如果选择“带备份的就地主要版本升级”，创建的备份可用于在新部署中还原。

expiration for starting upgrade 允许您配置一个“超时”期限，升级任务必须在该期限内启动，否则将自动取消。此外，还要在暂存阶段提前测试升级，以确保在所需的时间窗口内完成升级。例如，如果您想在 1 小时内完成升级，而您测试过升级并知道升级需要 30 分钟，那么您的升级任务必须在您确认要升级后的 30 分钟内启动。因此，请将过期时间设置为 30 分钟，这样，如果在这段时间内没有启动，就不会占用您的窗口。

通过 API 进行升级

使用以下命令进行就地升级：

curl -X PATCH https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/version -H 'Authorization: Bearer <>' -H 'Content-Type: application/json' -d '{"version": "7.0"}'

expiration for starting upgrade 允许您配置一个“超时”期限，升级任务必须在该期限内启动，否则将自动取消。此外，还要在暂存阶段提前测试升级，以确保在所需的时间窗口内完成升级。例如，如果您想在 1 小时内完成升级，而您测试过升级并知道升级需要 30 分钟，那么您的升级任务必须在您确认要升级后的 30 分钟内启动。因此，将过期时间设置为 30 分钟后的时间戳，这样如果它没有在这段时间内启动，就不会超出您的窗口。过期时间必须在 5 分钟（默认）到 24 小时之间。更多信息，请参阅 Cloud Databases API。

通过 CLI 进行升级

在 CDB 插件版本 >= 中可用 0.20.0

要查看部署允许的升级和还原转换列表，请执行以下操作

ibmcloud cdb deployment-capability-show <NAME|CRN> versions

使用所需参数升级命令：

ibmcloud cdb deployment-version-upgrade <NAME|CRN> <TARGET_VERSION>

要查看命令参数的全部详细信息：

ibmcloud cdb deployment-version-upgrade --help

通过 Terraform 进行升级

适用于 Terraform 提供程序版本 >= 1.79.2

要升级，只需在配置中添加或更改 version 值即可。还有一个可选的 bool 标志 version_upgrade_skip_backup，可以设置为跳过备份。

不建议跳过备份。在版本升级前不进行备份是很危险的，如果升级在任何阶段失败，都可能导致数据丢失，因为没有即时备份可以恢复。

升级期间，数据库将进入“只读”模式。强烈建议在升级前进行测试。

升级可能需要比默认超时更长的时间。可以使用 timeouts 属性设置更长的超时值。

Terraform 有超时而不是过期时间戳。因此，请增加超时时间，因为超时更新值会被用作过期时间。例如，如果设置超时 20 分钟，过期时间将被设置为 20 分钟，如果在该时间段内没有开始升级，则过期时间将被设置为 20 分钟，升级将不会开始。请注意，最长过期时间为 24 小时，因此即使设置了 36 小时的超时时间，如果在 24 小时内没有开始升级，升级也会过期。

如果正在进行升级，请注意某些任务可能处于排队状态，在版本升级完成之前不会继续执行。

故障诊断

用户 bypassWriteBlockingMode

为确保安全升级，在备份或升级过程中，任何用户都不能执行写入操作。在数据库进入写入块模式之前，会检查是否有用户拥有以下权限 bypassWriteBlockingMode. 如果识别到这样的用户，任务就会进入失败状态。任何重试都会失败，只有删除具有这种权限的用户，才能执行就地主要版本升级。

健康检查

如果服务实例资源不足，任务就会失败，因为在这种情况下无法保证安全升级。资源消耗可通过监控集成进行评估。如果不是所有数据库组件都可以升级，升级任务就会失败。这可能是维修造成的。因健康检查失败而失败的任务可以稍后重试。如果任务持续失败，请向 IBM Cloud 支持中心提交支持票据。

从备份复原

在数据库的主要版本达到生命周期终点（EOL）之前，通过将备份恢复到新的数据库实例，升级到下一个可用的主要版本。

准备在 EOL 日期之前的最新版本上运行，然后迁移到该版本。有关更多信息，请参阅版本控制策略。

不支持回滚版本。

升级到可用于 Databases for MongoDB的最新版本的 MongoDB。从目录页面，Cloud Databases CLI 插件命令 ibmcloud cdb deployables-show 或 Cloud Databases API /deployables 端点中查找最新版本。

通过将数据的备份复原到新部署来处理升级。从备份复原具有各种优点:

原始数据库保持运行，并且可以不中断生产工作。
可以在生产环境外部测试新数据库，并对任何应用程序不兼容性采取行动。
整个过程可在任何时候重新运行。
全新恢复可降低旧版本数据库中不需要的人工痕迹被带到新数据库中的可能性。

升级路径

主要版本升级路径
当前版本	主要版本升级路径
MongoDB 6	MongoDB 7

在 UI 中升级

对于新的托管模式（隔离计算和共享计算），可通过 CLI 和 API 升级到新的主版本。

您可以通过恢复备份从 备份和恢复 控制台上部署的 IBM Cloud 页面升级到新版本。单击备份上的 恢复备份，在新选项卡中打开一个页面，您可以在其中更改新部署的一些选项。其中一个是数据库版本，将自动填充可供您升级到的版本。选择一个版本，然后单击 Restore backup 开始配置和还原过程。

通过 CLI 进行升级

通过 IBM Cloud CLI 从备份升级和复原时，请使用资源控制器中的供应命令。

ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE_ID> <SERVICE_PLAN_ID> <REGION>

参数 instance_name，service_id，service_plan_id 和 region 都是必需的。您还可以在 JSON 对象中提供具有版本和备份标识参数的 -p。在备份时，将使用与源部署相同的磁盘和内存自动调整新部署的大小。

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":"7.0"
}'

通过 API 进行升级

与通过 API 进行配置类似，您必须完成使用资源控制器 API 所需的步骤，然后才能使用它从备份进行升级。然后，向 API 发送 POST 请求。参数 name，target，resource_group 和 resource_plan_id 都是必需的。同时提供版本和备份 ID。新部署与备份时的源部署具有相同的内存和磁盘分配。

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": "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":"7.0"
  }'

通过 Terraform 进行升级

使用 Terraform 将备份从旧版本还原到新版本。

设置您的 backup_id。有关更多信息，请参阅 backup_id。
在版本属性中设置 version。有关更多信息，请参阅 version。

代码如下

resource "ibm_database" "<your-instance>" {
  name                                 = "<your_database_name>"
  service                              = "<service>"
  plan                                 = "<plan>"
  location                             = "<region>"
  version                              = "<version>"
  backup_id                            = "<backup_id>"
}

更多信息，请参阅 Cloud Databases Terraform 注册表。