PostgreSQL upgrades =================== .. raw:: html PostgreSQLのアップグレードは、2つのカテゴリに分類されます。 - :ref:`マイナーバージョンのアップグレード <マイナーバージョンのアップグレード>` 例 17.0から17.1 - :ref:`メジャーバージョンのアップグレード <メジャーバージョンのアップグレード>` 例、16.xから17.0 マイナーバージョンのアップグレード ---------------------------------- PostgreSQLバージョン番号は\ ``major.minor`` 形式に従います。例、バージョン17.1では - ``17`` はメジャーバージョンです - ``1`` はマイナーバージョンです マイナーリリースは、同じメジャーバージョンの以前および後のマイナーリリースと完全な互換性があります。これらにはバグ修正とセキュリティ更新が含まれていますが、内部ストレージ形式への変更は導入されません。 CloudNativePGのマイナーバージョンのアップグレード ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 新しいマイナーバージョンにアップグレードするには、クラスター定義のPostgreSQLコンテナイメージ参照を直接またはイメージカタログを介して更新するだけです。 CloudNativePGは :ref:`rolling update of the cluster ` をトリガーし、各インスタンスをレプリカから1つずつ置き換えます。すべてのレプリカが更新されると、プライマリのスイッチオーバーまたは再起動が実行されてプロセスが完了します。 メジャーバージョンのアップグレード ---------------------------------- PostgreSQLのメジャーリリースでは、内部データストレージ形式の変更が導入され、より構造化されたアップグレードプロセスが必要です。 CloudNativePGは、メジャーアップグレードを実行するための3つの方法をサポートしています。 1. :ref:`Logical dump/restore ` – ブルー/グリーン展開、オフライン。 2. :ref:`Native logical replication ` – ブルー/グリーン展開、オンライン。 3. ``pg_upgrade`` を使用した物理的 – インプレースアップグレード、オフライン 以下の :ref:`PostgreSQLのオフラインインプレースメジャーアップグレード ` でカバーされています。 各方法には、ダウンタイム、複雑さ、データ量の処理の点でトレードオフがあります。最適なアプローチは、アップグレード戦略と操作の制約によって異なります。 .. Note:: 運用アップグレードを続行する前に、制御された環境ですべてのメソッドをテストすることを強くお勧めします。 　 オフラインインプレースメジャーアップグレード -------------------------------------------- CloudNativePGは、より高いPostgreSQLメジャーバージョンを使用した新しいオペランドコンテナイメージがクラスターで宣言的に要求された場合、 **オフラインインプレースメジャーアップグレード** を実行します。 .. Note:: メジャーアップグレードは、同じオペレーティングシステムディストリビューションに基づくイメージ間でのみサポートされています。たとえば、以前のバージョンで`bullseye` イメージを使用している場合、`bookworm` イメージにアップグレードすることはできません。 　 .. Warning:: PostgreSQL 17.0〜17.5にはバグがあり、`max_slot_wal_keep_size` パラメーターが`-1` 以外の値に設定されている場合、アップグレードの成功を妨げます。アップグレードプロセスは、レプリケーションスロット構成に関連するエラーで失敗します。この号は `fixed in PostgreSQL 17.6 and 18beta2 or later versions `_ になりました。 PostgreSQL 17.0〜17.5を使用している場合は、メジャーアップグレードを試みる前に少なくともPostgreSQL 17.6にアップグレードするか、クラスター構成で`max_slot_wal_keep_size` パラメーターを`-1` に一時的に設定してください。 　 次の2つの方法のいずれかでアップグレードをトリガーできます。 - ``.spec.imageName`` オプションを介してイメージタグのメジャーバージョンを更新することにより。 - :ref:`Image Catalog ` を使用してバージョンの変更を管理する。 サポートされているイメージタグの詳細については、 :ref:`イメージタグの要件 <イメージタグの要件>` を参照してください。 .. Warning:: CloudNativePGはPostgreSQL拡張機能については責任を負いません。ソースPostgreSQLイメージの拡張機能がターゲットイメージの拡張機能と互換性があり、アップグレードパスがサポートされていることを確認する必要があります。予期しない問題を回避するために、事前にアップグレードプロセスを徹底的にテストしてください。 :ref:`extensions management feature ` 拡張機能のアップグレードを宣言的に管理するのに役立ちます。 　 アップグレードプロセス ^^^^^^^^^^^^^^^^^^^^^^ 1. すべてのクラスターポッドをシャットダウンして、データの一貫性を保証します。 2. 以前のPostgreSQLバージョンとイメージを\ ``.status.pgDataImageInfo`` の下のクラスターのステータスに記録します。 3. 新しいアップグレードジョブを開始します。 - イメージのバイナリとデータファイルがメジャーアップグレード要求と一致することを確認します。 - ``PGDATA`` 、および該当する場合はWALファイルとテーブルスペースの新しいディレクトリを作成します。 - 次を使用してアップグレードを実行します。 ``pg_upgrade`` ``--link`` オプションを使用した場合 - 正常に完了すると、元のディレクトリをアップグレードされた対応するディレクトリに置き換えます。 .. Warning:: アップグレードプロセス中、レプリカを含むPostgreSQLクラスター全体は、アプリケーションで使用できません。続行する前に、システムがこのダウンタイムを許容できることを確認してください。 　 .. Warning:: インプレースアップグレードの実行は、固有のリスクを伴う例外的な操作です。アップグレードプロセスを開始する前に、クラスターの完全なバックアップを作成することを強くお勧めします。 　 .. Note:: `pg_upgrade` の詳細なガイダンスについては、公式 `PostgreSQL documentation `_ を参照してください。 　 アップグレード後のアクション ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ アップグレードが成功した場合、CloudNativePGは次のことを行います。 - レプリカのPVCを破壊します利用可能な場合。 - 必要に応じて、レプリカをスケールアップします。 .. Warning:: レプリカの再クローン作成は、特に非常に大規模なデータベースの場合、時間がかかる場合があります。潜在的な遅延に対応できるように、それに応じて計画を立てます。アップグレードが完了したら、完全なバックアップを取ることを強くお勧めします。既存のバックアップデータつまりベースバックアップとWALファイルは、以前のマイナーPostgreSQLリリースでのみ使用できます。 　 .. Warning:: `pg_upgrade` は、オプティマイザー統計を転送しません。アップグレードの後、データベースで`ANALYZE` を実行して更新することができます。 　 CloudNativePGはロールバックを自動的に決定できないため、アップグレードが失敗した場合は、クラスターの構成のメジャーバージョンの変更を手動で元に戻し、アップグレードジョブを削除する必要があります。 .. Note:: このプロセスは、アップグレード中にデータが変更されないため、**既存のデータベースをデータ損失から保護します**。アップグレードが失敗した場合、通常はバックアップから完全なリカバリを実行せずにロールバックが可能です。プロセスを注意深く監視し、必要に応じて修正アクションを実行します。 　 例メジャーアップグレードの実行 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ バージョン16を実行している次のPostgreSQLクラスターを検討します。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Cluster metadata: name: cluster-example spec: imageName: ghcr.io/cloudnative-pg/postgresql:16-minimal-trixie instances: 3 storage: size: 1Gi 次のコマンドを使用して、現在のPostgreSQLバージョンを確認できます。 .. code:: sh kubectl cnpg psql cluster-example -- -qAt -c SELECT version() これにより、次のような出力が返されます。 .. code:: console PostgreSQL 16.x ... クラスターをバージョン17にアップグレードするには、メジャーバージョンタグを\ ``16`` から\ ``17`` に変更して、\ ``imageName`` フィールドを更新します。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Cluster metadata: name: cluster-example spec: imageName: ghcr.io/cloudnative-pg/postgresql:17-minimal-trixie instances: 3 storage: size: 1Gi .. _アップグレードプロセス-1: アップグレードプロセス ^^^^^^^^^^^^^^^^^^^^^^ 1. クラスターのシャットダウン – 一貫したアップグレードを保証するために、すべてのクラスターポッドが終了します。 2. アップグレードジョブの実行 – 新しいジョブは、プライマリポッドの名前にサフィックス ``-major-upgrade`` を追加した名前で作成されます。このジョブは、プライマリの永続ボリュームグループで\ ``pg_upgrade`` を実行します。 3. アップグレード後の手順 - レプリカのPVCグループ ``cluster-example-2`` および\ ``cluster-example-3`` が削除されます。 - プライマリポッドが再起動されます。 - 2つの新しいレプリカ ``cluster-example-4`` および\ ``cluster-example-5`` が、アップグレードされたプライマリから再クローンされます。 アップグレードが完了すると、同じコマンドを実行して新しいメジャーバージョンを確認できます。 .. code:: sh kubectl cnpg psql cluster-example -- -qAt -c SELECT version() これにより、次のような出力が返されます。 .. code:: console PostgreSQL 17.x ... ``app`` データベースで\ ``ANALYZE`` を実行することにより、統計を更新できるようになりました。 .. code:: sh kubectl cnpg psql cluster-example -- app -c ANALYZE