Postgres Instance Manager

CloudNativePGは、フェールオーバー管理に外部ツールに依存しません。これは、Kubernetes APIサーバーと、 Postgresインスタンスマネージャー と呼ばれるネイティブキーコンポーネントに依存するだけです。

インスタンスマネージャーは、PostgreSQLサーバープロセスpostmaster としても知られるライフサイクル全体を処理します。

新しいクラスターを作成すると、オペレーターはインスタンスごとにポッドを作成します。フィールド.spec.instances は、作成するインスタンスの数を指定します。

各ポッドは、メインコンテナの親プロセスPID 1としてインスタンスマネージャーを起動し、PostgreSQLインスタンスを実行します。ポッドのライフタイム中、インスタンスマネージャーはバックエンドとして機能して startup, liveness and readiness probes を処理します。

スタートアッププローブ

起動プローブは、PostgreSQLインスタンスがプライマリかスタンバイかにかかわらず、完全に起動していることを確認します。

注釈

デフォルトでは、起動プローブは pg_isready を使用します。ただし、別の起動戦略を指定することにより、動作をカスタマイズできます。 startupプローブの実行中、livenessプローブとreadnessプローブは無効のままです。 Kubernetes標準に従って、startupプローブが失敗すると、kubeletはコンテナを終了し、再起動します。

.spec.startDelay パラメーターは、startupプローブが成功するまでに許可される最大時間を秒単位で指定します。

デフォルトでは、startDelay は3600 秒に設定されます。特定の環境でPostgreSQLが完全に初期化する必要がある時間に基づいて、この設定を調整することをお勧めします。

警告

.spec.startDelay の設定が低すぎると、livenessプローブが途中でアクティブ化され、PostgreSQLが完全に初期化されていない場合は不必要なPodが再起動する可能性があります。 CloudNativePGは、次のデフォルトパラメーターを使用して起動プローブを構成します。

failureThreshold: FAILURE_THRESHOLD
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5

failureThreshold 値は、 startDelay をperiodSeconds で除算することにより自動的に計算されます。

構成の.spec.probes.startup セクションでプローブ設定をカスタマイズできます。

警告

カスタムプローブ設定がクラスターの操作要件に合わせて調整されていることを確認して、意図しない中断を回避します。 !!!注意プローブ構成の詳細については、 probe API documentation を参照してください。 .spec.probes.startup.failureThreshold を手動で指定すると、デフォルトの動作がオーバーライドされ、startDelay の自動使用が無効になります。

たとえば、次の構成は、 startDelay をバイパスして、カスタムプローブパラメーターを明示的に設定します。

#  ... snip

spec:
  probes:
    startup:
      periodSeconds: 3
      timeoutSeconds: 3
      failureThreshold: 10

スタートアッププローブ戦略

特定のシナリオでは、PostgreSQLクラスターの起動戦略をカスタマイズする必要がある場合があります。たとえば、プライマリからストリーミングを開始するまでレプリカを開始済みとしてマーキングするのを遅らせるか、レプリカの準備ができていると見なされる前に満たす必要があるレプリケーションラグしきい値を定義できます。

これらの要件に対応するために、CloudNativePGは2つのオプションのパラメーターで.spec.probes.startup スタンザを拡張します。

type プローブが成功したとみなすための基準を指定します。受け入れられる値、複雑さ/深さの順に、次のものが含まれます。
- pg_isready pg_isready コマンドが0 で終了したときに、プローブを成功としてマークします。これは、プライマリインスタンスとレプリカのデフォルトです。
- query 基本的なクエリーがpostgres データベースでローカルに実行されたときにプローブを成功としてマークします。
- streaming レプリカがソースからストリーミングを開始し、指定された条件を満たしたときにプローブを成功としてマークします。ラグ要件詳細以下。
maximumLag バイト単位で測定される最大許容レプリケーションラグを定義しますKubernetes量として表現されます。このパラメーターは、 type がstreaming に設定されている場合にのみ適用されます。 maximumLag が指定されない場合、レプリカはストリーミングを開始するとすぐに正常に開始されたとみなされます。

#  <snip>

probes:
  startup:
    type: streaming
    maximumLag: 16Mi

Liveness Probe

livenessプローブは、startupプローブが正常に完了した後に開始されます。その主な役割は、PostgreSQLインスタンスマネージャーが正常に動作していることを確認することです。

Kubernetes標準に従って、livenessプローブが失敗すると、kubeletはコンテナを終了し、再起動します。

ポッドが生きていないとして分類されるまでの時間は、 .spec.livenessProbeTimeout パラメーターを介して構成できます。

CloudNativePGは、次のデフォルトパラメーターを使用してlivenessプローブを構成します。

failureThreshold: FAILURE_THRESHOLD
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5

failureThreshold 値は、 livenessProbeTimeout をperiodSeconds で除算することにより自動的に計算されます。

デフォルトでは、.spec.livenessProbeTimeout は30 秒に設定されます。これは、livenessプローブが、各チェックの間に10秒の間隔で、3回連続したプローブ障害を検出した場合に障害を報告することを意味します。

構成の.spec.probes.liveness セクションでプローブ設定をカスタマイズできます。

警告

カスタムプローブ設定がクラスターの操作要件に合わせて調整されていることを確認して、意図しない中断を回避します。 !!!注意プローブ構成の詳細については、 probe API documentation を参照してください。 .spec.probes.liveness.failureThreshold を手動で指定すると、デフォルトの動作がオーバーライドされ、livenessProbeTimeout の自動使用が無効になります。

たとえば、次の構成は、 livenessProbeTimeout をバイパスして、カスタムプローブパラメーターを明示的に設定します。

#  ... snip

spec:
  probes:
    liveness:
      periodSeconds: 3
      timeoutSeconds: 3
      failureThreshold: 10

プライマリ分離

CloudNativePG 1.27では、PostgreSQLプライマリの活性プローブの追加動作を導入し、次の条件の両方が満たされる場合に障害を報告します。

インスタンスマネージャーはKubernetes APIサーバーに到達できません
インスタンスマネージャーは、インスタンスマネージャーのREST APIを介して他のインスタンスに到達できません

この動作の効果は、分離されたプライマリが生きていないと考えられ、その後、livenessプローブが失敗したときに シャットダウン します。

デフォルトで有効になっています 。以下を追加して無効にできます。

spec:
  probes:
    liveness:
      isolationCheck:
        enabled: false

spec:
  probes:
    liveness:
      isolationCheck:
        enabled: true
        requestTimeout: "2000"
        connectionTimeout: "2000"

Readiness Probe

スタートアッププローブが正常に完了すると、準備状況プローブが開始されます。その主な目的は、PostgreSQLインスタンスがポッドのライフサイクル中の任意の時点でトラフィックを受け入れ、要求を処理する準備ができているかどうかを確認することです。

注釈

デフォルトでは、準備状況プローブは pg_isready を使用します。ただし、別の準備状況戦略を指定することにより、動作をカスタマイズできます。 Kubernetes標準に従って、準備状況プローブが失敗した場合、ポッドは未準備としてマークされ、どのサービスからトラフィックを受信しません。準備ができていないポッドは、自動フェイルオーバーシナリオ中のプロモーションの対象外です。

CloudNativePGは、準備状況プローブに次のデフォルト構成を使用します。

failureThreshold: 3
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5

デフォルト設定が要件に合わない場合は、 .spec.probes.readiness スタンザでパラメーターを指定して、readnessプローブを完全にカスタマイズできます。例

#  ... snip

spec:
  probes:
    readiness:
      periodSeconds: 3
      timeoutSeconds: 3
      failureThreshold: 10

警告

カスタムプローブ設定がクラスターの操作要件と一致していることを確認して、意図しない中断を防ぎます。 !!!注プローブの構成の詳細については、 probe API を参照してください。

Readness Probe戦略

特定のシナリオでは、クラスターの準備状況戦略をカスタマイズする必要がある場合があります。たとえば、プライマリからストリーミングを開始するまでレプリカの準備ができていることのマーキングを遅らせるか、レプリカの準備ができていると判断する前に最大レプリケーションラグしきい値を定義できます。

これらの要件に対応するために、CloudNativePGは2つのオプショナルパラメーターtype およびmaximumLag で.spec.probes.readiness スタンザを拡張しました。スタートアッププローブ戦略を参照してください。

これらのオプションの詳細については、セクションを参照してください。

フェールオーバー中のプロモーションまたは同期レプリケーションクォーラムへの参加など、キーオペレーター機能からのレプリカの除外。 - 読み取り/読み取り専用サービスの中断。 - フェールオーバー時間が長いシナリオでは、レプリカの準備ができていないと宣言され、手動介入が必要なクラスターストールが発生する場合があります。

#  <snip>

probes:
  readiness:
    type: streaming
    maximumLag: 64Mi
    failureThreshold: 30
    periodSeconds: 10

シャットダウン制御

Postgresを実行しているポッドが手動で、またはノードドレイン操作に続いてKubernetesによって削除されると、kubeletはインスタンスマネージャーに終了信号を送信し、インスタンスマネージャーは適切な方法でPostgreSQLのシャットダウンを担当します。 .spec.smartShutdownTimeout および.spec.stopDelay オプションは秒単位であり、PostgreSQLがシャットダウンするまでの時間を制御します。値はデフォルトでそれぞれ180および1800秒です。

シャットダウン手順は2つの手順で構成されます。

インスタンスマネージャーは、最初にCHECKPOINT を発行し、次に スマート シャットダウンを開始し、PostgreSQLへの新しい接続を禁止します。このステップは最大.spec.smartShutdownTimeout 秒間続きます。
PostgreSQLがまだアップしている場合、インスタンスマネージャーは高速シャットダウンを要求し、既存の接続を終了してすぐに終了します。インスタンスがWALファイルのアーカイブおよび/またはストリーミングを行っている場合、プロセスは.spec.stopDelay で設定された残り時間まで待機して操作が完了し、強制的にシャットダウンします。このようなタイムアウトは少なくとも15秒である必要があります。

スイッチオーバー中のプライマリのシャットダウン

スイッチオーバー中のシャットダウン手順は、一般的な場合と少し異なります。元のプライマリのインスタンスマネージャーは、最初にCHECKPOINT を発行し、指定された新しいプライマリが昇格する前にPostgreSQLの高速シャットダウンを開始し、新しいプライマリですべてのデータが安全に利用できるようにします。

このため、秒単位で表される.spec.switchoverDelay は、元のプライマリが正常にシャットダウンし、すべてのWALファイルをアーカイブする時間を制御します。デフォルトでは、3600 1時間に設定されています。

警告

.spec.switchoverDelay オプションは PgBouncerPoolMode に影響します

とPostgreSQLデータベースのバックアップ頻度とRTO 低い値に設定すると、RPOよりもRTOが優先される場合がありますが、クラスターレベルおよび/またはバックアップレベルでデータの損失が発生します。逆に、高い値に設定すると、スイッチオーバー中にアクティブなプライマリのないクラスターを長時間放置する間のデータ損失のリスクを取り除くことができます。

フェイルオーバー

プライマリポッドに障害が発生した場合、クラスターはフェールオーバーモードになります。詳細は FailoverQuorum を参照してください。

ディスクフル障害

ストレージの枯渇は、PostgreSQLクラスターのよく知られた問題です。 PostgreSQL documentation

では、考えられる障害シナリオと、ディスクの使用状況を監視してディスクがいっぱいになるのを防ぐことの重要性を強調しています。

同じことはCloudNativePGとKubernetesにも当てはまります。バックアップの進行状況のモニタリング

WALセグメントが使用するディスク領域と、Prometheusにエクスポートされたディスク使用量の標準メトリックの確認に関する詳細を提供します。

これにより、人間の管理者は根本的な原因に対処できます。

このような場合、ストレージクラスでサポートされている場合、現在最も早いアクションは次のことです。

フルPVCのストレージサイズを拡張する
Cluster リソースのサイズを同じ値に増加します

問題が解決され、WALセグメント用の十分な空き領域が確保されると、ポッドが再起動し、クラスターが正常な状態になります。

ドキュメントのボリュームの拡張も参照してください。