ローリングアップデート
======================
.. raw:: html
オペレーターを使用すると、アプリケーションが実行されているときにクラスターで使用されるPostgreSQLバージョンを変更できます。
.. Important::
PostgreSQLマイナーリリースのアップグレードのみがサポートされています。
ローリングアップグレードは、次の場合に開始されます。
- ユーザーはクラスター仕様の\ ``imageName`` 属性を変更します。
- :ref:`イメージカタログ <イメージカタログ>` は、クラスターが使用するメジャーの新しいイメージで更新されます。
- PostgreSQL構成を変更するには、再起動を適用する必要があります。
- ``Cluster`` ``.spec.resources`` 値の変更
- AKSの永続ボリューム要求のサイズの変更
- オペレーターが更新された後、ポッドが最新のインスタンスマネージャーを実行していることを確認します
:ref:`in-place updates are enabled <インストールとアップグレード>` の場合
オペレーターは、一度に1つのポッドずつ、すべてのレプリカのアップグレードを開始します。シリアルが最も高いものから開始します。
プライマリは、アップグレードされる最後のノードです。
ローリング更新は構成可能で、完全に自動化する\ ``unsupervised``
か、人間の介入を必要とする\ ``supervised`` のいずれかです。
アップグレードでは、データの再クローンを作成せずに、CloudNativePG
IDを維持します。ポッドは削除され、必要に応じて同じPVCと新しいイメージを使用して再度作成されます。
ローリング更新手順中に、各サービスエンドポイントが移動してクラスターのステータスを反映するため、アプリケーションは更新中のノードを無視できます。
自動更新 ``unsupervised``
-------------------------
``primaryUpdateStrategy`` が\ ``unsupervised``
に設定されている場合、ローリング更新プロセスはKubernetesによって管理され、完全に自動化されます。レプリカがアップグレードされると、選択された\ ``primaryUpdateMethod``
オペレーションがプライマリで開始されます。これはデフォルトの動作です。
``primaryUpdateMethod`` オプションは、次のいずれかの値を受け入れます。
- ``restart``
可能であれば、プライマリインスタンスが実行されているポッドの自動再起動を実行します。それ以外の場合、再起動要求は無視され、スイッチオーバーが発行されます。これはデフォルトの動作です。
- ``switchover``
スイッチオーバー操作が自動的に実行され、最もアライメントされたレプリカを新しいターゲットプライマリとして設定し、以前のプライマリポッドをシャットダウンします。
データベースの実際のワークロード、
:ref:`PgBouncerPoolMode {postgresql-cnpg-io-v1-PgBouncerPoolMode} ` および :ref:`RTOとRPOのインパクト ` に関する要件、PostgreSQLアーキテクチャが共有されているか、何も共有されていないなどのいくつかの要素に依存するため、
update方法に万能の構成はありません。で。
実際、PostgreSQLはプライマリ/スタンバイアーキテクチャのデータベース管理システムであるため、更新プロセスは必然的にアプリケーションのダウンタイムを生成します。コンテキストに合わせて考慮する必要がある重要な側面の1つは、ポッドが新しいPostgreSQLコンテナイメージをダウンロードするのにかかる時間です。これは、Kubernetesクラスターの設定と仕様によって異なります。
``switchover``
メソッドは、昇格したインスタンスがコンテナのターゲットイメージバージョンを既に実行していることを確認します。代わりに
``restart``
メソッドでは、プライマリポッドがシャットダウンされた後、元のレジストリからイメージをダウンロードする必要がある場合があります。データベースにとって、ローリング更新プロシージャの一部として\ ``restart``
または\ ``switchover``
を使用することが最善であるかどうかは、あなたが判断する必要があります。
手動更新 ``supervised``
-----------------------
``primaryUpdateStrategy`` が\ ``supervised``
に設定されている場合、ローリング更新プロセスは、すべてのレプリカがアップグレードされた直後に一時停止されます。
このフェーズは、手動スイッチオーバーまたはインプレースリスタートのいずれかでのみ完了できます。イメージのアップグレードはインプレース再起動では適用できないため、このような場合にはスイッチオーバーが必要であることに注意してください。
次の方法でスイッチオーバーをトリガーできます。
.. code:: bash
kubectl cnpg promote [cluster] [new_primary]
次の方法で再起動をトリガーできます。
.. code:: bash
kubectl cnpg restart [cluster] [current_primary]
詳細については、 :ref:`Backup {postgresql-cnpg-io-v1-Backup} ` を参照してください。