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