確認すべき拡張機能および論理レプリケーションオブジェクト

アップグレードの前に、以下の項目を確認してください：

pg_repack

アップグレード前に pg_repack を削除し、アップグレード後に再作成してください。 pg_repack はバージョン固有の拡張機能とクライアント／サーバーコンポーネントを使用しており、これらは PostgreSQL のメジャーバージョンと一致している必要があります。

DROP EXTENSION pg_repack;

アップグレード後は、ワークロードで引き続きその拡張機能が必要な場合にのみ、再作成してください。

CREATE EXTENSION pg_repack;

old_snapshot

アップグレードの前に、 old_snapshot を削除してください。 PostgreSQL 18へのアップグレード後は、サポート対象外となるため、再作成しないでください。

DROP EXTENSION old_snapshot;

wal2json レプリケーションスロット

論理デコードに wal2json を使用している場合は、アップグレード前に、関連するすべてのレプリケーションスロットを削除する必要があります。 pg_upgrade ユーティリティは、レプリケーションスロットが存在している間はメジャーバージョンのアップグレードを厳格に禁止しており、重大なエラーを発生させてアップグレードを中止します。

アップグレード前：

1. 未処理のWALデータがすべて処理済みであることを確認してください。
2. レプリケーションスロットを使用しているアプリケーションを停止してください。
3. レプリケーションスロットを削除する：

SELECT pg_drop_replication_slot('your_slot_name');

アップグレード後、必要に応じてレプリケーションスロットを再作成できます。 なお、 wal2json は CREATE EXTENSION を使用してインストールされるのではなく、データベースパラメータ（wal_level、 max_replication_slots、 max_wal_senders ）およびテーブルの権限を通じて設定されるため、アップグレードの妨げにはなりません。

anon

アップグレードの前に「 anon 」拡張機能を無効にし、アップグレード後も引き続き必要であれば、再度有効にしてください。 anon を削除する前に、追加の手順が必要です。

「 anon 」拡張機能がインストールされている場合は、アップグレードを実行する前に、以下の手順を完了し、管理者ユーザーとしてコマンドを実行してください。

1. すべてのマスキングルールを削除する（有効な場合）。

   SELECT anon.remove_masks_for_all_columns();
   

2. ロールのマスク機能を無効にします（ロールがマスクされていると、アップグレードに失敗する可能性があります）。

   SECURITY LABEL FOR anon ON ROLE <role_name> IS NULL;
   

3. カスケード・オプションで anon のエクステンションを削除する。

   DROP EXTENSION anon CASCADE;
   

4. インスタンス内の複数のデータベースに anon 拡張機能がインストールされている場合は、各データベースについて、記載された手順を実行してください。

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

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

PostGIS

PostGIS, をご利用の場合は、 PostgreSQL をアップグレードする前に、まず PostGIS をアップグレードしてください。

SELECT postgis_extensions_upgrade();

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

SELECT postgis_full_version();

Logical replication slots

アップグレードの前に、すべての論理レプリケーションスロットを削除し、アップグレード後にそれらを再作成してください。 論理スロットはソースサーバーの状態に紐づいているため、アップグレード後のインスタンス上でクリーンな状態で再作成する必要があります。

SELECT pg_drop_replication_slot('<slot_name>');

開始前に

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

• UI、API、CLI、またはTerraformを使用してデプロイ機能情報を確認し、現在のデプロイバージョンに対してバージョンアップが利用可能かどうかを確認してください。

  例：CLI を使用してバージョンのアップグレード情報を確認する：

  ibmcloud cdb capability-show versions postgresql
  

• IPUを起動する前に、必ずこのトピックに記載されている事前チェックに関する要件を確認してください。 IPUはソース環境上で直接実行され、新しいインスタンスは作成されません。 お客様安全を確保するため、本サービスではアップグレード開始前に事前チェックを実施し、リスクが検出された場合は操作をブロックします。 特に、以下の項目を確認してください：

  • このデプロイメントには、最大で3人のメンバーがいます。
  • デプロイメントの状態は正常です。
  • デプロイメントには、少なくとも10%の空きディスク容量があります。 IPU事前チェックにおけるデフォルトのディスク使用率の上限は90%です。
  • お客様の環境では、I/Oへの負荷はそれほど高くないようです。 IPUプレチェックのデフォルトの最大許容I/O使用率は90%です。
  • スキーマのサイズとオブジェクト数は、デフォルトの事前チェックの閾値の範囲内です。 デフォルトでは、個々のスキーマのサイズは100 GBを超えてはならず、インデックスとシーケンスの合計数は50,000件以下でなければなりません。
  • アップグレードの前に、必要な拡張および論理レプリケーションスロットのクリーンアップをすべて完了しました。

• 各メジャーバージョンには、以前のバージョンとの下位互換性がない機能が含まれている場合があります。 データベースベンダーの リリースノート を確認し、アプリケーションに影響を与える可能性のある変更点がないか確認してください。

• デプロイメントを以前のバージョンにダウングレードすることはサポートされていません。

• メジャーバージョンのインプレースアップグレードは、開始後はキャンセルできません。

• 最新のバックアップがない場合は、アップグレードを行う前にバックアップを取ることを検討してください。

なお、アップグレードが完了すると、データベースの PostgreSQL のメジャーバージョンが更新される点にご注意ください。 PostgreSQL はデータをバージョン固有の形式で保存するため、アップグレード前のバックアップやPITRポイントは以前のバージョンのタイムラインに属しており、アップグレード後のバージョンには復元できません。 新しいバージョンでも完全な復元およびPITR（特定時点への復旧）機能を維持するには、アップグレード完了直後に新しいバックアップを作成してください。 そのバックアップは、新しいバージョンのタイムラインにおける今後の復旧作業の基準となります。

IPUが失敗した場合でも、アップグレード前の有効なバックアップを使用し、PITR（ポイント・イン・タイム・リストア）によって、以前の PostgreSQL バージョンを新しいインスタンスに復元することができます。

トラブルシューティング

アプリケーションがメジャーバージョンのインプレースアップグレード後に予期せぬ問題を示し、以前の PostgreSQL バージョンに戻す必要がある場合は、サポートチームまでご連絡ください。 復旧作業を複雑にする恐れがあるため、ご自身でPITRを開始したり、バックアップを復元したりすることは避けてください。

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

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

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

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

ドライ・ランを実行するには、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
    }
}' \