新しいメジャー・バージョンへのアップグレード

UI でのアップグレード

1. アップグレード処理をテストするために、新しい Databases for Elasticsearch を作成します。
   同じバージョンの既存の配置から バックアップを復元して 配置を作成します。

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": "8.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を通じて 新しいメジャー・バージョンへのアップグレードが可能です。

IBM Cloud コンソールの配置の [バックアップと復元] ページからバックアップを 復元する ことで、新しいバージョンにアップグレードできます。 バックアップのバックアップを復元] をクリックすると、新しいタブでページが開き、新しい配置のオプションをいくつか変更できます。 その 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-elasticsearch enterprise us-south \
-p \ '{
  "backup_id": "crn:v1:bluemix:public:databases-for-elasticsearch:us-south:a/54e8ffe85dcedf470db5b5ee6ac4a8d8:1b8f53db-fc2d-4e24-8470-f82b15c71717:backup:06392e97-df90-46d8-98e8-cb67e9e0a8e6",
  "version":"8.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-elasticsearch-enterprise",
    "backup_id": "crn:v1:bluemix:public:databases-for-elasticsearch:us-south:a/54e8ffe85dcedf470db5b5ee6ac4a8d8:1b8f53db-fc2d-4e24-8470-f82b15c71717:backup:06392e97-df90-46d8-98e8-cb67e9e0a8e6",
    "version":"8.0"
  }'

Terraformによるアップグレード

Terraformを使って、古いバージョンから新しいバージョンへのバックアップにリストアする。

1. backup_id を設定する。 細については、 backup_idを参照してください。
2. version属性に version。 細については、 versionを参照してください。

コードは以下のようになる：

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

詳細については、 Cloud Databases Terraform Registryを参照のこと。 あるいは、 Terraform IBM Modules(TIM) を使って、バックアップインスタンスから新しいデータベースインスタンスを作成することもできます。 詳細については、 バックアップからのリストアの例を参照してください。