升级到新主版本

第2代

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

就地升级至新主要版本（目前支持 MongoDB 标准版）。
从备份中恢复（支持 MongoDB 标准版、MongoDB 企业版）。

就地进行主要版本升级

就地主版本升级可让您将部署升级至下一个新主版本，从而无需将备份恢复到新的部署中。这种方法保留了相同的连接字符串，无需重新配置部署。不过，如果新主版本需要对应用程序进行调整，则必须解决这些问题。

在就地主要版本升级期间（包括备份），部署环境将设置为 setUserWriteBlockMode 模式，该模式仅允许对部署环境进行读取操作，但不允许写入操作，以确保升级安全进行。一旦部署的主版本升级完成，writeBlockMode 将被移除。

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

带备份的原地主版本升级：此方法会在执行实际升级之前创建备份，从而提供额外的安全保障。
不进行备份的就地主版本升级：此选项将在不事先创建备份的情况下进行升级。如果就地升级失败，您需要从最新备份中恢复部署，并将其部署到一个新的环境中。

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

准备工作

在开始升级流程之前，请考虑以下方面。

升级前，您的部署必须处于正常状态。
您的部署环境必须至少有 2 GB 的可用磁盘空间。
您的部署中不得存在具有以下权限的用户：bypassWriteBlockingMode。
您只能升级到下一个主要版本，而不能指定您想要的版本。
每个主要版本都包含一些可能与先前版本不向后兼容的功能。请查阅数据库供应商发布的版本说明，以了解可能影响您应用程序的任何变更。
不支持将部署降级到以前的版本。
就地主版本升级一旦开始，便无法取消。
对于 MongoDB Enterprise Edition，在升级之前必须至少有一个可用的备份。

在用户界面中进行升级

创建一个新的 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 的值即可。此外还有一个可选的布尔标志 version_upgrade_skip_backup，您可以将其设置为跳过备份。

不建议跳过备份。在版本升级前跳过备份操作非常危险，如果升级在任何阶段失败，可能会导致数据丢失——因为此时没有可立即用于恢复的备份。

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

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

Terraform 使用超时机制，而非过期时间戳。因此，请延长超时时间，因为您的超时更新值将被用作过期时间。例如，如果您将超时时间设置为 20 分钟，则过期时间将设为 20 分钟；如果升级在此时间段内未开始，则该操作将过期，升级也不会启动。请注意，最长有效期为 24 小时——因此，即使您将超时时间设置为 36 小时，如果升级在前 24 小时内未开始，该升级也将失效。

如果正在进行版本升级，请注意，某些任务可能会被放入队列，并将在版本升级完成后才会继续执行。

故障诊断

用户拥有 bypassWriteBlockingMode

为确保升级安全，在备份或升级过程中，任何用户都不得执行写入操作。在数据库进入写入阻塞模式之前，系统会检查是否有用户拥有 bypassWriteBlockingMode。如果识别出此类用户，该任务将进入失败状态。任何重试都会失败，只有移除此类权限的用户，才能执行就地主版本升级。

健康检查

如果服务实例的资源不足，任务将失败，因为在这种情况下无法保证安全升级。可以通过监控集成来评估资源消耗情况。如果并非所有数据库组件都可供升级，则升级任务将失败。这可能是由于维护工作造成的。因健康检查失败而失败的任务，稍后可以重试。如果任务持续失败，请向 IBM Cloud 支持团队提交支持工单。

从备份复原

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

请做好准备，在产品生命周期结束（EOL）日期之前运行最新版本，并迁移至该版本。如需了解更多信息，请参阅《版本控制政策》。

不支持回滚版本。

请升级至 MongoDB 的最新版本，该版本可从 Databases for MongoDB 下载。您可以通过目录页面、Cloud Databases CLI 插件命令 ibmcloud cdb deployables-show，或 Cloud Databases API 的 /deployables 端点查找最新版本。

升级是通过将您的数据还原备份到新部署中来完成的。从备份中恢复数据有以下优点：

原始数据库保持运行，并且可以不中断生产工作。
可以在生产环境外部测试新数据库，并对任何应用程序不兼容性采取行动。
整个过程可以在任何时候重新运行。
进行一次全新的还原操作，可以降低旧版本数据库中不必要的残留数据被带入新数据库的可能性。

升级路径

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

在用户界面中进行升级

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

您可以通过在 IBM Cloud 控制台的部署 “备份与还原”页面中还原备份，来升级到新版本。在某个备份上点击“还原备份”，将在新标签页中打开一个页面，您可以在其中更改新部署的一些选项。其中之一是数据库版本，系统会自动填充可供您升级的可用版本。选择一个版本，然后点击 “还原备份”以开始配置和还原过程。

通过命令行界面（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 均为必填项。您还需要将版本和备份 ID 参数作为 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。有关更多信息，请参阅 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 Registry。