Azure Database for PostgreSQL フレキシブルサーバーでのメジャーバージョンのアップグレード

Azure Database for PostgreSQL フレキシブルサーバーは、PostgreSQL バージョン 18、17、16、15、14、13、12、11 をサポートしています。 Postgres コミュニティでは、新機能を含む新しいメジャーバージョンを年に 1 回程度リリースしています。さらに、各メジャーバージョンでは、マイナーリリースの形式で定期的なバグ修正を受け取ります。マイナーバージョンのアップグレードには、既存のアプリケーションと下位互換性のある変更が含まれます。 Azure Database for PostgreSQLフレキシブルサーバーは、お客様のメンテナンス期間中にマイナーバージョンを定期的に更新します。

メジャーバージョンのアップグレードは、マイナーバージョンのアップグレードよりも複雑です。既存のアプリケーションと下位互換性のない内部変更や新機能を含めることができます。

Azure Database for PostgreSQLフレキシブルサーバーには、サーバーのインプレースメジャーバージョンアップグレードを実行する機能があります。この機能では、サーバーにアクセスするユーザーとアプリケーションの中断を最小限に抑えることで、アップグレードプロセスを簡略化します。

インプレースアップグレードでは、メジャーバージョンのアップグレード後も、現在のサーバーのサーバー名やその他の設定が保持されます。データの移行やアプリケーション接続文字列の変更は必要ありません。インプレースアップグレードはデータ移行よりも迅速で、ダウンタイムが短縮されます。

注

Azure Database for PostgreSQLでは、現在サポートされている PostgreSQL バージョンへのインプレースメジャーバージョンのアップグレードのみがサポートされます。ターゲットバージョンは、アップグレード時にAzureによって正式にサポートされている必要があります。 Azure ポータルでは、サポートされていないバージョンを選択できませんが、非推奨のバージョンを対象とする API または CLI 呼び出しは失敗します。メジャーバージョンのアップグレードを開始する前に、常に Azure PostgreSQL のバージョン管理ポリシーおよびアップグレードのハウツーガイドを参照してください。

アップグレードの検証チェック

Azure Database for PostgreSQLフレキシブルサーバーでは、アップグレード検証チェックが提供され、メジャーバージョンのアップグレードを開始する前にアップグレードの準備状況を評価できます。

アップグレード検証チェックでは、サーバーに対して一連の互換性と構成の検証が実行され、アップグレードが失敗したり、予期せず動作したりする可能性のある条件が特定されます。一般的なチェックには、サポートされていない拡張機能、論理レプリケーションスロット、準備されたトランザクション、イベントトリガー、サポートされていないオブジェクトの依存関係、再起動が必要な構成変更の保留中などがあります。

検証プロセスは、実際のアップグレード操作を開始せずにアップグレードの準備状況を評価するように設計されています。メジャーバージョンのアップグレードワークフロー中にも、同じ検証チェックが自動的に実行されます。これらのチェックでは、サーバーのバージョンの変更、ダウンタイムのトリガー、サーバーの再起動は行われません。運用アップグレード期間をスケジュールする前に検証チェックを実行します。

アップグレード検証チェックは、Azure ポータルまたはAzure CLIで実行できます。手順については、「アップグレード検証チェックの実行」を参照してください。

検証が完了すると、次のいずれかの結果が返されます。

ブロックの問題が検出されませんでした:アップグレード検証チェックが正常に完了し、アップグレードをブロックする問題が特定されませんでした。
ブロック中の問題が検出されました: アップグレード検証チェックでは、アップグレードを続行する前に解決する必要がある 1 つ以上の問題が特定されました。

結果に応じて、アップグレードを続行するか、報告された問題を修復して検証を再実行できます。

制限事項

アップグレード検証チェックを使用する場合は、次の制限事項を考慮してください。

サーバーの状態は 準備完了である必要があります。
検証チェックは、読み取りレプリカではサポートされていません。
別のサーバー操作が既に進行中の間は、検証を実行できません。
検証チェックでは、サーバー上のすべてのデータベースへの接続が必要です。応答しないデータベースまたはアクセスできないデータベースでは、検証エラーが発生する可能性があります。
検証チェックではダウンタイムは発生しませんが、データベースアクティビティが低下する期間中は実行することを検討してください。

詳細な手順については、「アップグレード検証チェックの実行」を参照してください。

アップグレードプロセス

メジャーバージョンのインプレースアップグレードを行う際に留意すべき重要な点は以下の通りです:

アップグレードを開始する前に、サーバーで少なくとも 10 から 20% 空きストレージが使用可能であることを確認します。アップグレードプロセス中に、一時ログファイルとメタデータ操作によってディスク使用量が増加する可能性があります。空き領域が不足すると、アップグレードエラーやロールバックの問題が発生する可能性があります。
インプレースメジャーバージョンアップグレードのプロセス中に、Azure Database for PostgreSQLフレキシブルサーバーは事前チェック手順を実行して、アップグレードが失敗する可能性のある潜在的な問題を特定します。
- 事前チェックで非互換性が見つかった場合、アップグレードの事前チェックが失敗したことを示すログイベントがエラーメッセージと共に作成されます。
- 事前チェックが成功した場合、Azure Database for PostgreSQLフレキシブルサーバーはサービスを停止し、アップグレードを開始する直前に暗黙的なバックアップを取得します。アップグレードエラーが発生した場合、サービスはこの暗黙的バックアップを使用して、データベースインスタンスを以前のバージョンに復元できます。
Azure Database for PostgreSQLフレキシブルサーバーでは、pg_upgrade ツールを使用してインプレースメジャーバージョンのアップグレードを実行します。このサービスでは、バージョンをスキップし、新しいバージョンに直接アップグレードする柔軟性が提供されます。
高可用性 (HA) が有効になっているサーバーのインプレースメジャーバージョンアップグレード中、サービスは HA を無効にし、プライマリサーバーでアップグレードを実行し、アップグレードが完了した後に HA を再度有効にします。 HA を再度有効にするには、新しいスタンバイインスタンスをプロビジョニングするのに十分な容量が必要です。
ほとんどの拡張機能は、インプレースメジャーバージョンアップグレード中に新しいバージョンに自動的にアップグレードされますが、一部例外があります。
Azure Database for PostgreSQL フレキシブルサーバーのインプレースメジャーバージョンアップグレードのプロセスでは、サポートされている最新のマイナーバージョンが自動的にデプロイされます。
アップグレード期間は、オブジェクト (テーブル、インデックス、スキーマ)、ラージオブジェクト、拡張機能の数など、データベースのサイズと複雑さによって異なります。大規模または複雑なワークロードでは、アップグレード時間が長くなる可能性があります。
アップグレード前の長時間実行トランザクションや高いワークロードにより、データベースのシャットダウンにかかる時間とアップグレードの所要時間が長くなる可能性があります。
インプレースメジャーバージョンアップグレードが成功した後、自動で以前のバージョンに戻す方法はありません。新しいサーバーで以前のバージョンを復元するために、アップグレード前の時点への特定の時点への復旧 (PITR) を実行できます。
Azure Database for PostgreSQL サーバーをセキュリティで保護します。 Azure Database for PostgreSQLフレキシブルサーバーでメジャーバージョンをアップグレードした後、サーバー上に作成された最初のユーザー (ADMIN オプションが付与されます) は、重要なメンテナンス操作のために他のロールに対する管理特権を持つようになりました。

アップグレードに関する考慮事項と制限事項

インプレースメジャーバージョンのアップグレード中に事前チェック操作が失敗した場合、アップグレードプロセスは停止し、詳細なエラーメッセージが表示されます。次の既知の制限により、アップグレードが失敗したり、予期せず動作したりする可能性があります。

Important

アップグレードの互換性要件は、ソースとターゲットの PostgreSQL のバージョンによって異なり、時間の経過と同時に変化する可能性があります。このセクションの一覧は一般的なリファレンスであり、アップグレードパスの正確なチェックが反映されていない可能性があります。アップグレードをスケジュールする前に、サーバーに対してアップグレード検証チェックを実行して、論理レプリケーションスロットの要件を含め、特定のアップグレードをブロックする問題の現在の権限のあるセットを取得します。

サポートされていないサーバー構成

Azure Database for PostgreSQL の geo レプリケーションは、インプレースアップグレード中にはサポートされていません。プライマリサーバーをアップグレードする前に、読み取りレプリカ (カスケード読み取りレプリカを含む) を削除する必要があります。アップグレード後、レプリカを作成し直すことができます。
ネットワークトラフィックルールによって、アップグレード操作がブロックされる場合があります。
- フレキシブルサーバーが仮想ネットワーク内のポート 5432 と 6432 でトラフィックを送受信し、(ログアーカイブ用に) Azure Storageできることを確認します。
- ネットワークセキュリティグループ (NSG) がこのトラフィックを制限している場合、高可用性 (HA) はアップグレード後に自動的に再有効化されません。 NSG ルールを手動で更新し、HA を再度有効にする必要がある場合があります。
メジャーバージョンのアップグレード中、 pg_stat_activity に依存するビューはサポートされません。
PostgreSQL 11 から上位バージョンにアップグレードする場合は、SCRAM を有効にし、すべての認証ロールパスワードをリセットすることで、SCRAM 認証を使用するようにフレキシブルサーバーを構成する必要があります。

拡張機能の制限事項

インプレースでのメジャーバージョンアップグレードでは、すべての PostgreSQL 拡張機能をサポートしているわけではありません。ブロックされた拡張機能が影響を受けるアップグレードパスに存在する場合、事前チェック中にアップグレードは失敗します。次の一覧に示すように、ほとんどのブロックは、すべてのアップグレードではなく、特定の ターゲット (および場合によっては ソース) のバージョンにスコープが設定されます。

次の拡張機能は 、すべてのアップグレードパスでのインプレースメジャーバージョンのアップグレードをブロックします。アップグレードの前にそれらを削除し、ターゲットバージョンでサポートされている場合は後で再度有効にします( session_variable、 anon、 age)。
次の拡張機能は 非永続的ユーティリティ拡張機能 であり、アップグレードの前に削除し、設計 (すべてのアップグレードパス) によって再作成する必要があります。 pg_repack、 hypopg、 pg_partman。

次の拡張機能は、特定の バージョンパスでのみブロックされます。アップグレードが一覧の条件と一致する場合は、アップグレード前にそれらを削除し、ターゲットバージョンでサポートされている場合は後で再度有効にします。

Extension	ブロックされるタイミング
`pg_hint_plan`	ターゲットバージョンは PostgreSQL 14 です
`semver`	ターゲットバージョンは PostgreSQL 16 または 17 です
`azure_local_ai`	ターゲットバージョンは PostgreSQL 17 または 18 です
`pg_failover_slots`	ターゲットバージョンが PostgreSQL 17 または 18 (共有プリロードライブラリ)
`azure_ai`	ターゲットバージョンは PostgreSQL 18 です
`azure_storage`	ターゲットバージョンは PostgreSQL 18 です
`pg_diskann`	ターゲットバージョンは PostgreSQL 18 です
`pgrouting`	ターゲットバージョンは PostgreSQL 15 です。またはソースが PostgreSQL 16 より前で、ターゲットが PostgreSQL 16 以降です。またはターゲットバージョンが PostgreSQL 18 である
`orafce`	ソースバージョンは PostgreSQL 11、12、または 13 です

他のデータベースオブジェクトがオブジェクト に依存している場合、アップグレードが失敗するため、次の拡張機能はブロックされます。アップグレード前に依存関係を解決します。
- pg_stat_statements: 他のオブジェクトがビューまたは関数に依存するとブロックされ、 ALTER EXTENSION pg_stat_statements UPDATE が失敗します。最初に依存オブジェクトを削除します。
- pgcrypto: pg_catalog スキーマにインストールされ、PostgreSQL 11 または 12 から PostgreSQL 13 以降にアップグレードすると、顧客オブジェクトがそれに依存するとブロックされます (組み込みの gen_random_uuid() 関数との競合)。拡張機能を別のスキーマに再配置するか、依存オブジェクトを最初に削除します。

注

アップグレードする前に、'DROP EXTENSION' 操作を実行して、サポートされていない拡張機能を削除する必要があります。許可リストから拡張機能を削除する必要はありません。

PostGIS 固有の考慮事項

PostGIS または依存拡張機能を使用している場合は、 search_path パラメーターを次のように構成します。

PostGIS に関連するスキーマ
依存拡張機能( postgis、 postgis_raster、 postgis_sfcgal、 postgis_tiger_geocoder、 postgis_topology、 address_standardizer、 address_standardizer_data_us、 fuzzystrmatch
search_pathを正しく構成しないと、アップグレードが失敗したり、アップグレード後にオブジェクトが中断されたりする可能性があります。

TimescaleDB 固有の考慮事項

TimescaleDB を使用している場合、インプレースメジャーバージョンのアップグレードは、特定の PostgreSQL ソースとターゲットのバージョンの組み合わせでのみサポートされます。

ソース PostgreSQL のバージョン	サポートされているターゲットバージョン
PostgreSQL 11	PostgreSQL 12
PostgreSQL 12	PostgreSQL 13、14、15
PostgreSQL 13	PostgreSQL 14、15、16
PostgreSQL 14	PostgreSQL 15、16
PostgreSQL 15	PostgreSQL 16、17、18
PostgreSQL 16	PostgreSQL 17、18
PostgreSQL 17	PostgreSQL 18

サポートされているマトリックスに TimescaleDB アップグレードパスが一覧表示されていない場合、インプレースメジャーバージョンのアップグレードはブロックされます。続行するには、アップグレードの前に TimescaleDB 拡張機能を削除するか、可能であれば、論理レプリケーションを使用したサイドバイサイド移行などの代替移行アプローチを使用します。

アップグレードを開始する前に、ソースとターゲットのバージョンがサポートされているマトリックスに含まれていることを確認します。

その他のアップグレードに関する考慮事項

イベントトリガー: アップグレードの事前チェックは、DDL コマンドにフックされ、メジャーバージョン間で変更されるシステムカタログを参照する可能性があるため、イベントトリガーをブロックします。アップグレードする前にすべての EVENT TRIGGERを削除し、アップグレード後に再作成して、スムーズなアップグレードを確保します。
ラージオブジェクト (LO): アップグレードで何百万ものラージオブジェクト ( pg_largeobjectに格納されている) を含むデータベースを処理する方法は、ターゲットメジャーバージョンによって異なります。
- ターゲット PostgreSQL 15 以降: アップグレードでは、最適化された一括メソッドを使用してラージオブジェクトメタデータを転送するため、メモリと一時ディスクの使用量は、ラージオブジェクトの数に応じてスケーリングされなくなります。数千万から数億個のラージオブジェクトを含むデータベースは、追加の準備なしで確実にアップグレードされます。 vacuumloを実行したり、サーバーを事前にスケールアップしたりして、大きなオブジェクトボリュームを回避する必要はありませんが、vacuumloを実行して、他の理由で使用されていないラージオブジェクトを削除することもできます。
- ターゲット PostgreSQL 14 以前: 何百万もの大きなオブジェクトを含むデータベースでは、メモリ使用量またはログボリュームが多いためにアップグレードエラーが発生する可能性があります。バキュームロユーティリティを使用して未使用のラージオブジェクトをクリーンアップし、多数のラージオブジェクトがまだ使用されている場合は、アップグレード前にサーバーをスケールアップすることを検討してください。

Warnung

vacuumloには注意が必要です。 vacuumlo は、従来の参照列 (oid、lo) に基づいて孤立したラージオブジェクトを識別します。アプリケーションでカスタム参照型または間接参照型を使用している場合、有効なラージオブジェクトが誤って削除される可能性があります。さらに、 vacuumlo では、特に何百万ものラージオブジェクトを持つデータベースで、CPU、メモリ、IOPS が大幅に消費される可能性があります。メンテナンス期間中に実行し、最初に非運用環境でテストします。

アップグレード後

メジャーバージョンのアップグレードが完了したら、各データベースで ANALYZE コマンドを実行して、 pg_statistic テーブルを更新します。統計が見つからないか古い場合、クエリプランが不適切になり、パフォーマンスが低下し、過剰なメモリが占有される可能性があります。

postgres=> analyze;
ANALYZE

アップグレードログの表示

PG_Upgrade_Logsを使用してアップグレードの進行状況を監視し、問題のトラブルシューティングを行います。アップグレード中とアップグレード後のログを確認して、進行状況を追跡し、障害または遅延を診断し、ブロッキングの問題を特定して、迅速に是正措置を実行できるようにします。

サーバーログパラメーターを使用してアップグレードログを有効にする

logfiles.download_enableをオンに設定します。
logfiles.retention_daysを使用してリテンション期間を構成します。

開始するには、 PostgreSQL とアップグレードログのダウンロードに関するページを参照してください。

注

インプレースメジャーバージョンアップグレードは、自動移行されたサーバーでサポートされています。自動移行されたサーバーでインプレースメジャーバージョンのアップグレードが成功した後、ユーザー名の形式 username@servername はサポートされなくなりました。代わりに、標準形式の ユーザー名を使用します。認証の問題を回避するには、アップグレード後に更新されたユーザー名形式を使用するように、アプリケーションとスクリプト内のすべての接続文字列を慎重に確認して更新します。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-08-06