ローリングアップデート¶
オペレーターは、アプリケーションの実行中にクラスターで使用されるPostgreSQLバージョンを変更できます。
重要
PostgreSQLマイナーリリースのアップグレードのみがサポートされています。
ローリング アップグレードは次の場合に開始されます。
ユーザーがクラスター仕様の
imageName属性を変更します。PostgreSQL構成の変更には、再起動を適用する必要があります。
Cluster.spec.resourcesの値の変更AKSでの永続ボリューム要求のサイズの変更
- オペレーターが更新された後、ポッドが最新のインスタンスマネージャーを実行するようにします（
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]
詳細については、 cnpg を参照してください。
