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