ローリングアップデート
オペレーターを使用すると、アプリケーションが実行されているときにクラスターで使用されるPostgreSQLバージョンを変更できます。
重要
PostgreSQLマイナーリリースのアップグレードのみがサポートされています。
ローリングアップグレードは、次の場合に開始されます。
ユーザーはクラスター仕様の
imageName属性を変更します。PostgreSQL構成を変更するには、再起動を適用する必要があります。
Cluster.spec.resources値の変更AKSの永続ボリューム要求のサイズの変更
オペレーターが更新された後、ポッドが最新のインスタンスマネージャーを実行していることを確認します in-place updates are enabled 場合を除きます。
オペレーターは、一度に1つのポッドずつ、すべてのレプリカのアップグレードを開始します。シリアルが最も高いものから開始します。
プライマリは、アップグレードされる最後のノードです。
ローリング更新は構成可能で、完全に自動化するunsupervised
か、人間の介入を必要とするsupervised のいずれかです。
アップグレードでは、データの再クローンを作成せずに、CloudNativePG IDを維持します。ポッドは削除され、必要に応じて同じ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]
詳細については、 Backup {postgresql-cnpg-io-v1-Backup} をご覧ください。