Rolling updates

オペレーターを使用すると、アプリケーションの実行を継続しながら、クラスターで使用されるPostgreSQLバージョンを変更できます。

ローリングアップグレードは、次の場合にトリガーされます。

  • クラスター仕様のimageName 属性を変更する場合。

  • クラスター仕様の.spec.postgresql.extensions スタンザの拡張イメージのリストを変更する場合。

  • Image Catalog は、クラスターが使用するメジャーバージョンの新しいイメージで更新されます。

  • PostgreSQL構成の変更を適用するには、再起動が必要です。

  • Cluster .spec.resources 値を変更します。

  • オペレーターが更新され、ポッドが最新のインスタンスマネージャーを実行します in-place updates are enabled の場合

ローリングアップグレード中に、オペレーターは、すべてのレプリカを一度に1つのポッドずつ、最も高いシリアルを持つものから始めてアップグレードします。

プライマリは常にアップグレードされる最後のノードです。

ローリング更新は構成可能で、完全に自動化するunsupervised か、人間の介入を必要とするsupervised のいずれかです。

アップグレードでは、データの再クローンを作成せずに、CloudNativePG IDを維持します。ポッドは削除され、必要に応じて同じPVCと新しいイメージを使用して再度作成されます。

ローリング更新手順中に、各サービスのエンドポイントが移動してクラスターのステータスを反映するため、アプリケーションは更新中のノードを無視できます。

自動更新 unsupervised

primaryUpdateStrategy がunsupervised に設定されている場合、ローリング更新プロセスはKubernetesによって管理され、完全に自動化されます。レプリカがアップグレードされると、選択されたprimaryUpdateMethod オペレーションがプライマリで開始されます。これはデフォルトの動作です。

primaryUpdateMethod オプションは、次のいずれかの値を受け入れます。

  • restart 可能であれば、プライマリインスタンスが実行されているポッドの自動再起動を実行します。それ以外の場合、再起動要求は無視され、スイッチオーバーが発行されます。これはデフォルトの動作です。

  • switchover スイッチオーバー操作が自動的に実行され、最もアライメントされたレプリカを新しいターゲットプライマリとして設定し、以前のプライマリポッドをシャットダウンします。

警告

primaryUpdateMethod が`switchover` に設定されている場合、イメージ名とPostgreSQL構成パラメーターを同時に変更することはできません。オペレーターは、このような更新を検証エラーで拒否します。イメージと構成の両方を更新する必要がある場合は、これらの変更を順番に実行する必要があります。最初にイメージを更新し、ローリング更新が完了するのを待って、構成を更新します。その逆も可能です。この制限は、新しいイメージバージョンに関連付けられた構成の変更が、スイッチオーバープロセス中に古いイメージを実行しているポッドに適用されると、PostgreSQLに障害を発生させる可能性があるために存在します。

データベースの実際のワークロード、 PgBouncerPoolMode および バックアップ頻度とRTO に関する要件、PostgreSQLアーキテクチャが共有されているか、何も共有されていないなどのいくつかの要素に依存するため、 update方法に万能の構成はありません。で。

実際、PostgreSQLはプライマリ/スタンバイアーキテクチャのデータベース管理システムであるため、更新プロセスは必然的にアプリケーションのダウンタイムを生成します。コンテキストに合わせて考慮する必要がある重要な側面の1つは、ポッドが新しいPostgreSQLコンテナイメージをダウンロードするのにかかる時間です。これは、Kubernetesクラスターの設定と仕様によって異なります。 switchover メソッドは、昇格したインスタンスがコンテナのターゲットイメージバージョンを既に実行していることを確認します。代わりに restart メソッドでは、プライマリポッドがシャットダウンされた後、元のレジストリからイメージをダウンロードする必要がある場合があります。データベースにとって、ローリング更新プロシージャの一部としてrestart またはswitchover を使用することが最善であるかどうかは、あなたが判断する必要があります。

手動更新 supervised

primaryUpdateStrategy がsupervised に設定されている場合、ローリング更新プロセスは、すべてのレプリカがアップグレードされた直後に一時停止されます。

このフェーズは、手動スイッチオーバーまたはインプレースリスタートのいずれかでのみ完了できます。イメージのアップグレードはインプレース再起動では適用できないため、このような場合にはスイッチオーバーが必要であることに注意してください。

次の方法でスイッチオーバーをトリガーできます。

kubectl cnpg promote [cluster] [new_primary]

次の方法で再起動をトリガーできます。

kubectl cnpg restart [cluster] [current_primary]

詳細については、 postgresql.cnpg.io/v1 を参照してください。