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

2025年12月現在、3つの異なる Databases for PostgreSQL アップグレードパスを提供しています：

新しいメジャーバージョンへのインプレースアップグレード。
バックアップからの復元中。
読み取り専用レプリカからのアップグレード。

データベースのメジャーバージョンがサポート終了（EOL）に近づいている場合、最新のメジャーバージョンへのアップグレードが推奨されます。

IBM Cloud カタログページ、 Cloud Databases CLI プラグイン・コマンド ibmcloud cdb deployables-show、または Cloud Databases API /deployables エンドポイントから、使用可能な Databases for PostgreSQL のバージョンを見つけます。

新規インスタンスにアップグレードする場合は、アプリケーション内の接続情報も変更する必要があります。

以下のコマンド例では、 {id} にデータベースインスタンスの完全な CRN が必要です。 CRNには特殊文字が含まれるため、「not_found」エラーを回避するには URL エンコードする必要があります。

より新しい PostgreSQL メジャーバージョンへのアップグレード PostgreSQL 要件 v14

pg_repackがインストールされている場合は、アップグレードを実行する前に削除する必要があります。これは、次のようなコマンドを使用して行うことができます。

DROP EXTENSION pg_repack;

アップグレード後に、 pg_repack を再インストールします。次のコマンドで実行できます:

CREATE EXTENSION pg_repack;

を使用している場合は、を PostGIS アップ PostGIS, グレードする前に、まずにアップグレードする必要があります PostgreSQL。これは、 PostGIS がインストールされたデータベースに対して以下のコマンドを実行することで実現できます。

SELECT postgis_extensions_upgrade();

以下のクエリーを使用して、 PostGIS 拡張機能のアップグレードを検証する。

SELECT postgis_full_version();

インプレースでのメジャーバージョンアップグレード

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

メジャーバージョンアップグレードのインプレース実施期間中、デプロイメントは一時的なダウンタイムを経験します。これは、ベンダー推奨のアップグレード手順に従っているため、予想されることです。正確な所要時間は、デプロイメントのスキーマの規模と複雑さによって異なる場合があります。この期間中にサービスがアップグレード対象インスタンスからデータを読み取る必要がある場合、スタンバイインスタンスを作成し、アプリケーションの接続先をスタンバイインスタンスに変更することを検討してください。これにより、アップグレードを開始する前に、データベースの最新コピーを確保できます。インプレースアップグレードが正常に完了しなかった場合、スタンバイインスタンスをプライマリインスタンスとして昇格させて使用することも可能です。追加情報は読み取り専用レプリカページで確認でき、こちらからご覧いただけます。

Databases for PostgreSQL 顧客が自身のバックアップを柔軟に管理できるようにします。インプレースでのメジャーバージョンアップグレード処理では、タスクの前後で自動的にバックアップが作成されることはありません。アップグレードが成功しない場合、最新のバックアップから新しいインスタンスにデプロイメントを復元する必要がある可能性があります。

インプレースアップグレードはサポートされていますが、最新のバックアップなしで実行することは推奨されません。アップグレード開始前と開始後に最新のバックアップを作成しておくことで、追加の保護層が提供され、必要に応じてスムーズな復旧経路を確保するのに役立ちます。したがって、インプレースでのメジャーバージョンアップグレード作業の前後で、新しいバックアップを作成することを検討してください。

開始前に

アップグレード手順を開始する前に、以下の点を考慮してください。

UI、API、CLI、またはTerraformを介してデプロイメント機能情報を確認し、デプロイメントバージョンに対してバージョンアップグレードが利用可能かどうかを確認してください。

例: CLI を使用してバージョンアップグレード情報を検索する。
```
ibmcloud cdb capability-show versions postgresql
```
アップグレード前に、デプロイメントが健全な状態にある必要があります。
デプロイメントには、ディスク容量の少なくとも10%が空き容量として確保されている必要があります。
デプロイメントは重いI/O負荷下にあるべきではありません（最大許容値：90%）。
現時点ではバージョン PostgreSQL 14から15 PostgreSQL へのアップグレードのみ可能です。
各メジャーバージョンには、以前のバージョンとの下位互換性がない可能性がある機能がいくつか含まれています。データベースベンダーのリリースノートを確認し、アプリケーションに影響を与える可能性のある変更点がないか確認してください。
デプロイメントを以前のバージョンにダウングレードすることはサポートされていません。
メジャーバージョンのインプレースアップグレードは、一度開始するとキャンセルできません。
最新のバックアップがない場合は、アップグレード前にバックアップを取ることを検討してください。

また、アップグレード完了後、データベースは新しい PostgreSQL メジャーバージョンで動作することにご注意ください。データはバージョン固有の形式で保存 PostgreSQL されるため、新しい PostgreSQL データディレクトリは以前のバージョンでは使用できません。これは、アップグレード前に作成されたバックアップは、新しい PostgreSQL バージョンへの復元に使用できないことを意味します。今後の完全復元およびPITR（ポイントインタイムリカバリ）機能を維持するためには、アップグレード後に新しいバックアップを取得してください。この新しいバックアップは、タイム PostgreSQL ラインにおける今後のすべての復旧操作の基準となります。

UI でのアップグレード

アップグレードプロセスをテストするために Databases for PostgreSQL 新しいを作成します。
既存のデプロイメントから同じバージョンのバックアップを復元して、デプロイメントを作成します。
ステージングアプリケーションをテストデプロイメントに指向してください。
ステージングアプリケーションを更新し、テストデプロイメントを指すようにしてください。テストアプリケーションがステージング環境への接続に成功し、アプリケーションが期待通りに動作することを確認してください。ステージング環境において必要な性能テストおよび運用テストを実施する。
テストデプロイメントのメジャーバージョンをアップグレードするには、概要ページにある 「メジャーバージョンをアップグレード」 ボタンをクリックしてください。
アップグレードが完了するまでの時間を確認し、アップグレードの有効期限設定を使用して、アップグレードをメンテナンスウィンドウ内に収めるようにしてください。
ステージング環境のアプリケーションが新しいデータベースバージョンで動作することを確認してください。
アプリケーションが正常に動作する場合、この手順により本番データベースのアップグレードが安全であることを確認できます。
本番データベースのデプロイメントを新バージョンにアップグレードしてください。
新しいバージョンのデータベースを使用してアプリケーションが正しく動作することを確認したら、管理コンソールに戻り、本番環境のデプロイメントのアップグレードプロセスを開始できます。概要ページの「 デプロイメントの詳細 」セクションで、「 メジャーバージョンをアップグレード 」ボタンをクリックし、手順に従ってください。

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

この 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": "15"}'

この expiration for starting upgrade 設定により、アップグレードジョブが自動的にキャンセルされる前に開始しなければならない「タイムアウト」期間を設定できます。さらに、アップグレードが所定の時間枠内で完了することを確認するため、事前にステージング環境でアップグレードをテストしてください。例えば、アップグレードを1時間以内に完了させたい場合、アップグレードをテスト済みで所要時間が30分と分かっているなら、アップグレードを開始する意思を確認してから30分以内にアップグレードジョブを開始する必要があります。したがって、有効期限を今から30分後のタイムスタンプに設定してください。そうすれば、その時間内に開始されなければ、あなたの作業時間をオーバーしないでしょう。有効期限は、現在時刻から5分後（デフォルト）から24時間後までの間でなければなりません。詳細については、 API Cloud Databases を参照してください。

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 ファイル内の値を追加または変更するだけです。

バージョンアップグレード前にバックアップをスキップすることは危険であり、アップグレードがどの段階で失敗してもデータ損失につながる可能性があります。復元可能な直近のバックアップが存在しないためです。したがって、インプレースでのメジャーバージョンアップグレード作業を開始する前に、新しいバックアップを作成することを検討してください。

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

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

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

トラブルシューティング

アプリケーションがメジャーバージョンのインプレースアップグレード後に予期せぬ問題を示し、以前の PostgreSQL バージョンに戻す必要がある場合は、サポートチームまでご連絡ください。 PITR（ポイント・イン・タイム・リカバリ）の開始やバックアップの復元を独自に行わないでください。これにより復旧が複雑化する可能性があります。

すべての事前チェックが完了するまで、インプレースでのメジャーアップグレードは実行されません。これらの保護策は、アップグレードがソースインスタンスに直接作用するため、デプロイメントを保護するために存在します。アップグレードがブロックされている場合は、以下の項目を確認してください：

クラスタ状態: Patroniクラスタが健全であり、明確なリーダー/レプリカ状態が存在することを確認してください。パトロニが不安定状態またはフェイルオーバー状態を報告している場合、アップグレードは実行できません。
ディスク容量: 十分な空き容量があることを確認してください。この pg_upgrade プロセスはリンクモードを使用しており、十分なヘッドルームが必要である。ディスク使用量が設定された制限値（デフォルト: 90%）を超えた場合、再試行前に空き領域を確保してください。
ディスクI/O負荷：現在のI/O使用率とIOPSを確認する。システムに高負荷がかかっている場合、パフォーマンスの低下やアップグレードの失敗を防ぐため、アップグレードは一時停止されます。
スキーマサイズとオブジェクト数: 前述の通り、スキーマサイズはインプレースでのメジャーバージョンアップグレードの所要時間に直接影響します。個々のスキーマが最大サイズ（デフォルト：100 GB）を超えないこと、およびインデックスとシーケンスオブジェクトの合計数が制限値（デフォルト：50,000）を下回っていることを確認してください。大規模なスキーマや異常に多いオブジェクト数は、アップグレードを進める前にクリーンアップや最適化が必要になる場合があります。 pg_upgrade 新しいシステムテーブルを作成し、古いユーザーデータファイルを再利用するだけで、迅速なアップグレードを実行します。これらのシステムテーブルの作成に必要な時間は、データベースオブジェクトの数に比例して増加します。リソース消費量は、監視統合機能を使用して評価できます。すべてのデータベースコンポーネントがアップグレード可能でない場合、アップグレードタスクは失敗します。これはメンテナンスが原因で発生する可能性があります。ヘルスチェックの失敗により失敗したタスクは、後で再試行できます。タスクが継続的に失敗する場合は、サポート IBM Cloud にサポートチケットを開いてください。特定のチェックがお客様の環境に関係なくアップグレードがブロックされる場合は、サポートチケットを作成して追加の支援を受けてください。

アップグレード前の `anon` 拡張機能の取り扱い

anon エクステンションがインストールされている場合は、アップグレードを実行する前に、以下の手順に従い、admin ユーザーとしてコマンドを実行してください。

すべてのマスキングルールを削除する（有効な場合）。
```
SELECT anon.remove_masks_for_all_columns();
```
ロールのマスク機能を無効にします（ロールがマスクされていると、アップグレードに失敗する可能性があります）。
```
SECURITY LABEL FOR anon ON ROLE <role_name> IS NULL;
```
カスケード・オプションで anon のエクステンションを削除する。
```
DROP EXTENSION anon CASCADE;
```
インスタンス内の複数のデータベースに anon エクステンションがインストールされている場合は、各データベースについて概略の手順に従ってください。
アップグレード後の手順

アップグレード完了後、 anon 拡張を再度有効にし、必要に応じてマスキングルールを再適用する。

アップグレードを実行する前に、マスキングの一貫性を確保するために、エクステンションを削除する前と後の両方でデータを検証することを強くお勧めします。

読み取り専用レプリカからのアップグレード

読み取り専用レプリカを構成することによってアップグレードします。デプロイメントと同じデータベースバージョンの読み取り専用レプリカを用意し、すべてのデータがレプリケートされるまで待機します。デプロイメントとそのレプリカが同期されたら、読み取り専用レプリカを昇格させ、アップグレードして、新しいバージョンのデータベースを実行する完全なスタンドアロンデプロイメントとして動作させます。アップグレードおよびプロモーション手順を実行するには、POSTリクエストを /deployments/{id}/remotes/promotion エンドポイントに送信し、リクエスト本文にアップグレード先のバージョンを指定します。

この要求は次のようになります。

curl -X POST \
  https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/remotes/promotion \
  -H 'Authorization: Bearer <>'  \
 -H 'Content-Type: application/json' \
 -d '{
    "promotion": {
        "version": "14",
        "skip_initial_backup": false
    }
}' \

skip_initial_backup はオプションです。 true に設定されている場合、新規デプロイメントは、プロモーションの完了時に初期バックアップを実行しません。新規デプロイメントは、次回の自動バックアップが実行されるか、オンデマンド・バックアップを実行するまでバックアップされないという犠牲を伴うことで、短時間で使用可能になります。

プロモーションとアップグレードのドライ・ラン

メジャーバージョンアップグレードの影響を評価するには、テスト実行をトリガーしてください。ドライランにより、プロモーションとアップグレードがシミュレートされ、結果がデータベース・ログに出力されます。ログ分析統合により、データベースのログにアクセスして表示できます。これにより、現在実行中のバージョンとその拡張機能が、目的のバージョンへ正常にアップグレードできることが保証されます。

ドライ・ランを実行するには、skip_initial_backup が false に設定されており、version が定義されている必要があります。

コマンドは次のようになります。

curl -X POST \
  https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/remotes/promotion \
  -H 'Authorization: Bearer <>'  \
 -H 'Content-Type: application/json' \
 -d '{
    "promotion": {
        "version": "14",
        "skip_initial_backup": false,
        "dry_run": true
    }
}' \

バックアップと復元によるアップグレード

新しいデータベース・バージョンを実行する新しいデプロイメントにデータのバックアップをリストアすることで、データベース・バージョンをアップグレードできます。

UI でのアップグレード

_デプロイメント・ダッシュボード_の 「バックアップ」 メニューからバックアップをリストアするときに、新規バージョンにアップグレードします。バックアップの [Restore] をクリックすると、新しいタブのプロビジョニングページが表示されます。オプションの一つはデータベースバージョンであり、アップグレード可能なバージョンが自動的に表示されます。バージョンを選択し、「作成」をクリックしてプロビジョニングと復元プロセスを開始します。

CLI を使用したアップグレード

IBM Cloud CLI を通じてバックアップからアップグレードおよび復元するには、リソースコントローラーのプロビジョニングコマンドを使用します。

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

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

このコマンドは、次のようになります。

ibmcloud resource service-instance-create example-upgrade databases-for-postgresql standard us-south \
-p \ '{
  "backup_id": "crn:v1:bluemix:public:databases-for-postgresql:us-south:a/54e8ffe85dcedf470db5b5ee6ac4a8d8:1b8f53db-fc2d-4e24-8470-f82b15c71717:backup:06392e97-df90-46d8-98e8-cb67e9e0a8e6",
  "version":14
}'

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": "bluemix-us-south",
    "resource_group": "5g9f447903254bb58972a2f3f5a4c711",
    "resource_plan_id": "databases-for-postgresql-standard",
    "backup_id": "crn:v1:bluemix:public:databases-for-postgresql:us-south:a/54e8ffe85dcedf470db5b5ee6ac4a8d8:1b8f53db-fc2d-4e24-8470-f82b15c71717:backup:06392e97-df90-46d8-98e8-cb67e9e0a8e6",
    "version":14
  }'

強制アップグレード

サポート終了日以降、非推奨バージョン上のすべての Databases for PostgreSQL アクティブなデプロイメントは、次のサポート対象バージョンへ強制的にアップグレードされます。例えば、 PostgreSQL バージョン13（非推奨）はバージョン14にアップグレードされます。

以下のようなリスクを避けるため、耐用年数終了前にアップグレードすること：

このタイプの強制アップグレードにはSLAは提供されない。
データが失われる可能性があります。
アプリケーションのダウンタイムが長引く可能性があります。
新しいバージョンと互換性がない場合、アプリケーションが動作しなくなる可能性があります。
このアップグレードのタイミングは、あなたの配備では制御できません。
この強制アップグレードにはロールバック処理はありません。

使用終了日については、バージョンポリシーのページを参照のこと。

バージョンアップ時の_管理者ユーザーの_問題

バージョン PostgreSQL 16 から、ロール特権の適用がより厳格になりました。対照的に、以前のバージョンでは、 CREATEROLE 属性を持つロールが他のロールを管理することができました。バージョン16以降では、あるロールが他のロールに ADMIN OPTION 、そのロールを許可または取り消す必要があります。

PostgreSQL v15 以前から PostgreSQL v16 以降にデータベースをアップグレードする場合、以下のような特権関連のエラーが発生することがあります：

ERROR: only roles with the ADMIN OPTION on role "some_role" may grant this role
DETAIL: role "admin" is not permitted to grant role "some_role"

この問題に対処するため、期待される役割管理の動作を復元するように設計された組み込みのヘルパー関数 grant_admin_option_to_roles。

この関数の特徴は、次のとおりです。

PostgreSQL v15 以前のバージョンから PostgreSQL 16 以降にアップグレードされたデータベースにのみ適用されます（上記のエラーが発生した場合）。
修正を適用するロールの任意のリストを受け付けます。
admin user によってのみ実行できる。
複数回実行しても安全である（idempotent）。

使用例:

SELECT grant_admin_option_to_roles('role1', 'role2', 'role3');

これにより、 admin user は、アップグレードされたインスタンスで指定されたロールを管理するための適切な ADMIN OPTION 権限を保持するようになります。

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

より新しい PostgreSQL メジャーバージョンへのアップグレード PostgreSQL 要件 v14

インプレースでのメジャーバージョンアップグレード

開始前に

UI でのアップグレード

API を使用したアップグレード

CLI を使用したアップグレード

Terraformによるアップグレード

トラブルシューティング

アップグレード前の anon 拡張機能の取り扱い

読み取り専用レプリカからのアップグレード

プロモーションとアップグレードのドライ・ラン

バックアップと復元によるアップグレード

UI でのアップグレード

CLI を使用したアップグレード

API を使用したアップグレード

強制アップグレード

バージョンアップ時の_管理者ユーザーの_問題

PostgreSQL のメジャー・バージョンの変更ログ

アップグレード前の `anon` 拡張機能の取り扱い