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

第2世代

Databases for MongoDB 2つの異なるアップグレードパスを提供しています：

  • 新しいメジャーバージョンへのインプレースアップグレード（現在、 MongoDB Standard Planでサポートされています）。
  • バックアップからの復元（ MongoDB のスタンダードプラン、 MongoDB のエンタープライズプランで対応）。

その場でのメジャーバージョンアップ

インプレースでのメジャーバージョンアップグレードにより、デプロイメントを次の新しい メジャーバージョン にアップグレードできるため、 バックアップを復元する を使用して新しいデプロイメントを作成する必要がなくなります。 このアプローチでは、デプロイメントの設定を変更することなく、同じ接続文字列を維持できます。 ただし、新しいメジャーバージョンによりアプリケーションの調整が必要となる場合は、それらに対応する必要があります。

その場でのメジャーバージョンアップグレード期間中（バックアップを含む）、デプロイメントは setUserWriteBlockMode に設定されます。これにより、安全なアップグレードを確保するため、デプロイメントに対する読み取り操作のみが許可され、書き込み操作は許可されません。 デプロイメントのメジャーバージョンアップグレードが完了次第、 writeBlockMode が削除されます。

メジャーバージョンのインプレースアップグレードを行う際には、2つの選択肢があります：

  • バックアップを伴うインプレースでのメジャーバージョンアップグレード：この方法では、実際のアップグレードを実行する前にバックアップを作成するため、安全性がさらに高まります。

  • バックアップを行わないインプレースでのメジャーバージョンアップグレード：このオプションでは、事前にバックアップを作成せずにアップグレードを実行します。 インプレースアップグレードが失敗した場合は、最新のバックアップから新しいデプロイメントにデプロイメントを復元する必要があります。

    バックアップを行わないインプレース・アップグレードは推奨されません。 アップグレードのどの段階で失敗しても、復元用の直近のバックアップが存在しないため、データが失われる可能性があります。

開始前に

アップグレード手順を開始する前に、以下の点についてご確認ください。

  • アップグレードを行う前に、デプロイメントが正常な状態である必要があります。
  • デプロイ先には、少なくとも 2 GB の空きディスク容量が必要です。
  • デプロイメントには、 bypassWriteBlockingMode。
  • 任意のバージョンを指定するのではなく、 次のメジャーバージョンへのアップグレードのみ可能です。
  • 各メジャーバージョンには、以前のバージョンとの下位互換性がない機能が含まれている場合があります。 データベースベンダーの リリースノート を確認し、アプリケーションに影響を与える可能性のある変更点がないか確認してください。
  • デプロイメントを以前のバージョンにダウングレードすることはサポートされていません。
  • インプレースでのメジャーバージョンアップグレードは、一度開始するとキャンセルできません。
  • MongoDB （ Enterprise Edition ）の場合、アップグレードを行う前に、少なくとも1つのバックアップが利用可能である必要があります。

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 」もあります。

バックアップを省略することは推奨されません。 バージョンアップの前にバックアップを省略するのは危険であり、アップグレードのどの段階で失敗しても、復元できる直近のバックアップが存在しないため、データが失われる可能性があります。

アップグレード中は、データベースが読み取り専用モードになります。 アップグレードを行う前に、必ずテストを行うことを強くお勧めします。

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

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

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

トラブルシューティング

以下のユーザー bypassWriteBlockingMode

アップグレードを安全に行うためには、バックアップやアップグレードの実施中は、どのユーザーも書き込み操作を行えないようにする必要があります。 データベースが writeBlockMode に入る前に、書き込みブロックモードを有効にする権限を持つユーザーがいるかどうかがチェックされます bypassWriteBlockingMode。 そのようなユーザーが特定された場合、タスクは失敗状態になります。 再試行しても失敗し、その権限を持つユーザーを削除して初めて、その場でのメジャーバージョンアップグレードを実行できるようになります。

ヘルスチェック

サービスインスタンスのリソースが不足している場合、このような状況下では安全なアップグレードが保証できないため、タスクは失敗します。 リソース消費量は、 監視機能との連携 を利用して評価することができます。 データベースのコンポーネントのすべてがアップグレード対象となっていない場合、アップグレード処理は失敗します。 これはメンテナンスが原因で発生することがあります。 ヘルスチェックの失敗により失敗したタスクは、後で再試行することができます。 タスクが繰り返し失敗する場合は、 IBM Cloud のサポート にサポートチケットを提出してください。

バックアップからのリストア

データベースのメジャーバージョンがサポート終了（EOL）を迎える前に、バックアップから新しいデータベースインスタンスに復元することで、利用可能な次のメジャーバージョンにアップグレードしてください。

EOL日までに、最新バージョンでの実行準備を整え、その後、最新バージョンへ移行してください。 詳細については、「 バージョン管理ポリシー 」を参照してください。

バージョンのロールバックはサポートされていません。

Databases for MongoDB で入手可能な、 MongoDB の最新バージョンにアップグレードしてください。 最新バージョンは、カタログページ、 Cloud Databases CLIプラグインのコマンド ibmcloud cdb deployables-show、または Cloud Databases APIのエンドポイント ` `/deployables から確認できます。

アップグレードは、データを新しいデプロイメントに バックアップの復元 することで行われます。 バックアップからの復元には、次のような利点があります：

  • 元のデータベースが実行されたままなので、実動作業を中断せずに実行できる。
  • 実動とは別に新規データベースをテストして、アプリケーションの非互換性がないかを確認できる。
  • 任意の時点でプロセス全体をやり直すことができる。
  • フレッシュ・リストアなので、前のバージョンのデータベースの不要な成果物が新規データベースに引き継がれる可能性が低くなる。

アップグレード・パス

メジャーバージョンのアップグレード手順
現行バージョン メジャー・バージョンのアップグレード・パス
MongoDB 7 MongoDB 8

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-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レジストリをご覧ください。