ローリングアップデート¶
オペレーターは、アプリケーションの実行中にクラスターで使用されるPostgreSQLバージョンを変更できます。
重要
PostgreSQLマイナーリリースのアップグレードのみがサポートされています。
ローリングアップグレードは、次の場合に開始されます。
ユーザーがクラスター仕様の
imageName属性を変更します。PostgreSQL構成の変更には、再起動を適用する必要があります。
Cluster.spec.resources値の変更AKSでの永続ボリューム要求のサイズの変更
- オペレーターが更新された後、Podが最新のインスタンスマネージャーを実行することを保証するため（
オペレーターは、一度に1つのPodですべてのレプリカのアップグレードを開始し、シリアルが最も高いものから開始します。
プライマリは、アップグレードする最後のノードです。
ローリングアップデートは構成可能で、完全に自動化（unsupervised
）することも、人間の介入を必要とする（supervised
）こともできます。
アップグレードでは、データを再クローンせずに、CloudNativePGのIDが保持されます。 Podは削除され、必要に応じて同じPVCと新しいイメージで再度作成されます。
ローリング更新手順中に、各サービスエンドポイントが移動してクラスターのステータスを反映するため、アプリケーションは更新中のノードを無視できます。
自動更新（unsupervised ）¶
primaryUpdateStrategy がunsupervised
に設定されている場合、ローリングアップデートプロセスはKubernetesによって管理され、完全に自動化されます。レプリカがアップグレードされると、選択したprimaryUpdateMethod
操作がプライマリで開始されます。これがデフォルトの動作です。
primaryUpdateMethod オプションは、次のいずれかの値を受け入れます。
restart：可能であれば、プライマリインスタンスが実行されているポッドの自動再起動を実行します。それ以外の場合、再起動要求は無視され、スイッチオーバーが発行されます。これがデフォルトの動作です。switchover：スイッチオーバー操作が自動的に実行され、最もアラインされたレプリカを新しいターゲットプライマリとして設定し、以前のプライマリポッドをシャットダウンします。
更新方法に万能の構成はありません。 データベースの実際のワークロード、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` プラグインを使用する>` を参照してください。
