UI でのアップグレード

1. アップグレードプロセスをテストするために、新しい Databases for MongoDB を作成します。
   同じバージョンの既存のデプロイメントから バックアップを復元 して、デプロイメントを作成します。

2. ステージング用アプリケーションのターゲットをテスト環境のデプロイ先に向ける。
   ステージングアプリケーションを更新し、テスト環境へのデプロイ先を指定してください。 テスト アプリケーションがステージング配置に正常に接続でき、アプリケーショ ンが期待どおりに動作することを確認します。 ステージング環境の必要なパフォーマンスおよび運用テストを実施する。

3. 「 概要 」ページの「 メジャーバージョンをアップグレード 」ボタンをクリックして、テスト環境のメジャーバージョンをアップグレードしてください。
   これにより、アップグレード処理が完了するまで、データベースが読み取り専用モードになります。 アップグレードが完了するまでの時間をメモしておくと、アップグレードの有効期限設定を使用して、メンテナンスウィンドウ内にアップグレードを含めることができます。

4. ステージング環境のアプリケーションが、新しいデータベースのバージョンで正常に動作することを確認してください。
   アプリケーションが正常に動作している場合、この手順により、本番環境のデータベースをアップグレードしても問題がないことが確認できます。

5. 本番用データベースの展開を新しいバージョンにアップグレードしてください。
   新しいバージョンのデータベースを使用してアプリケーションが正常に動作することを確認したら、管理コンソールに戻り、本番環境のアップグレードプロセスを開始できます。 概要] ページの [展開の詳細] セクションで、 [メジャーバージョンのアップグレード] ボタンをクリックし、手順に従ってください。

   いったんインプレース・アップグレード・プロセスが開始されると、それを停止したりロールバックしたりすることはできません。 そのため、万が一エラーが発生した場合、データベースの展開が回復できなくなる可能性があります。 したがって、新しい配置にリストアするために使用できるバッ クアップを作成します。 バックアップによるメジャーバージョンアップ」を選択した場合、作成されたバッ クアップは新しい配置での復元に使用できます。

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

expiration for starting upgrade では、アップグレードジョブが自動的にキャンセルされるまでの「タイムアウト」期間を設定できます。 さらに、アップグレードが希望する時間内に完了することを確認するために、前もってステージングでアップグレードをテストします。 例えば、1時間以内にアップグレードを完了したい場合、アップグレードをテストして30分かかることが分かっていれば、アップグレードジョブは、アップグレードしたいことを確認してから30分以内に開始しなければなりません。 そのため、有効期限を30分に設定し、その時間内に開始しなければウィンドウをオーバーしないようにする。 有効期限は5分後（デフォルト）から24時間後までの間でなければならない。 CLI --expire-in または --expire-at を使って有効期限を設定する方法は2つあります。 詳細については、コマンドのヘルプを参照してください。

Terraformによるアップグレード

Terraform プロバイダーのバージョンが 1.79.2 以上で利用可能です。

アップグレードするには、 version の値を追加または変更するだけです。 また、バックアップをスキップするために設定できるオプションのブールフラグ、 version_upgrade_skip_backup もあります。

バックアップをスキップすることは推奨されない。 バージョンアップの前にバックアップをスキップするのは危険であり、アップグレードがいずれかの段階で失敗した場合、データの損失につながる可能性があります。

アップグレード中、データベースはREAD-ONLYモードになります。 アップグレードの前にテストすることを強くお勧めします。

アップグレードには、デフォルトのタイムアウトよりも長い時間が必要な場合があります。 より長いタイムアウト値を設定するには、timeouts属性を使用します。

Terraformには有効期限タイムスタンプの代わりにタイムアウトがある。 したがって、タイムアウトの更新値が有効期限として使用されるため、タイムアウトを長くしてください。 例えば、タイムアウトを20分に設定した場合、有効期限は20分に設定され、その時間内にアップグレードが開始されなければ、有効期限が切れてアップグレードは開始されません。 タイムアウトを36時間に設定しても、最初の24時間以内にアップグレードが開始されなければ、アップグレードは失効します。

アップグレードが進行中の場合、いくつかのタスクはキューに入れられ、バージョンアップが完了するまで進行しないことに注意してください。

UI でのアップグレード

新しいホスティング・モデル（分離コンピュートおよび共有コンピュート）については、 CLI および APIを通じて 新しいメジャー・バージョンへのアップグレードが可能です。

You can upgrade to a new version by バックアップの復元 from the バックアップと復元 page of your deployment on the IBM Cloud console. バックアップの Restore backup をクリックすると、新しいタブでページが開き、新しい配置のオプションを変更できます。 その 1 つがデータベースのバージョンであり、アップグレードのターゲットにできるバージョンが自動的に取り込まれています。 バージョンを選択し、「 バックアップを復元 」をクリックして、プロビジョニングおよび復元プロセスを開始してください。

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 」はすべて必須です。 また、-p に、バージョンとバックアップ ID のパラメーターを JSON オブジェクトで指定してください。 新規デプロイメントは、バックアップ時のソース・デプロイメントと同じディスクおよびメモリーを適用して自動的にサイズ変更されます。

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を使って、古いバージョンから新しいバージョンへのバックアップにリストアする。

1. backup_id を設定する。 細については、 backup_idを参照してください。
2. 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を参照のこと。 あるいは、 Terraform IBM Modules(TIM) を使って、バックアップインスタンスから新しいデータベースインスタンスを作成することもできます。 詳細については、 バックアップからのリストアの例を参照してください。