Postgresインスタンスマネージャー ================================ CloudNativePGは、フェールオーバー管理に外部ツールに依存しません。これは、Kubernetes APIサーバーと、 **Postgresインスタンスマネージャー** と呼ばれるネイティブキーコンポーネントに依存するだけです。 インスタンスマネージャーは、PostgreSQLサーバープロセス\ ``postmaster`` としても知られるライフサイクル全体を処理します。 新しいクラスターを作成すると、オペレーターはインスタンスごとにポッドを作成します。フィールド\ ``.spec.instances`` は、作成するインスタンスの数を指定します。 各ポッドは、メインコンテナの親プロセスPID 1としてインスタンスマネージャーを起動し、PostgreSQLインスタンスを実行します。ポッドのライフタイム中、インスタンスマネージャーはバックエンドとして機能して `startup, liveness and readiness probes `_ を処理します。 スタートアップ、活性、および準備状況プローブ -------------------------------------------- スタートアップとライブネスプローブは\ ``pg_isready`` に依存しますが、準備状況プローブは、データベースが起動していて接続を受け入れることができるかどうかを確認します。 スタートアッププローブ ^^^^^^^^^^^^^^^^^^^^^^ ``.spec.startDelay`` パラメーターは、PostgreSQLポッドが起動した後にlivenessプローブがアクティブになるまでの遅延秒単位を指定します。デフォルトでは、これは\ ``3600`` 秒に設定されます。ご使用の環境でPostgreSQLが完全に初期化に必要な時間に基づいて、この値を調整する必要があります。 .. Warning:: `.spec.startDelay` の設定が低すぎると、livenessプローブが途中でアクティブ化される可能性があり、PostgreSQLが完全に初期化されていない場合は不必要なPodが再起動する可能性があります。 CloudNativePGは、次のデフォルトパラメーターを使用して起動プローブを構成します。 .. code:: yaml failureThreshold: FAILURE_THRESHOLD periodSeconds: 10 successThreshold: 1 timeoutSeconds: 5 ここで、 ``FAILURE_THRESHOLD`` は、 ``startDelay`` を\ ``periodSeconds`` で除算して計算されます。 ``startDelay`` に基づくデフォルトの動作がユースケースに適していない場合は、 ``.spec.probes.startup`` スタンザでカスタムパラメーターを指定することにより、起動プローブを完全に制御できます。このスタンザを定義すると、 ``startDelay`` の使用を含むデフォルトの動作がオーバーライドされることに注意してください。 .. Warning:: カスタムプローブ設定がクラスターの操作要件と一致していることを確認して、意図しない中断を防ぎます。 .. NOTE:: プローブ構成の詳細については、 :ref:`probe API ` を参照してください。 たとえば、次の構成は\ ``startDelay`` を完全にバイパスします。 .. code:: yaml # ... snip spec: probes: startup: periodSeconds: 3 timeoutSeconds: 3 failureThreshold: 10 Liveness Probe ^^^^^^^^^^^^^^ livenessプローブは、startupプローブが成功した後に開始され、PostgreSQLインスタンスがポッドの再起動が必要な壊れた状態に入ったかどうかを検出します。 ポッドが生きていないとして分類されるまでの時間は、 ``.spec.livenessProbeTimeout`` パラメーターを介して構成できます。 CloudNativePGは、次のデフォルトパラメーターを使用してlivenessプローブを構成します。 .. code:: yaml failureThreshold: FAILURE_THRESHOLD periodSeconds: 10 successThreshold: 1 timeoutSeconds: 5 ここで、 ``FAILURE_THRESHOLD`` は、 ``livenessProbeTimeout`` を\ ``periodSeconds`` で除算して計算されます。 デフォルトでは、\ ``.spec.livenessProbeTimeout`` は\ ``30`` 秒に設定されます。これは、livenessプローブが、各チェックの間に10秒の間隔で、3回連続したプローブ障害を検出した場合に障害を報告することを意味します。 ``livenessProbeTimeout`` を使用したデフォルトの動作がニーズを満たさない場合、 ``.spec.probes.liveness`` スタンザでパラメーターを定義することにより、livenessプローブを完全にカスタマイズできます。このスタンザを指定すると、 ``livenessProbeTimeout`` の使用を含むデフォルトの動作がオーバーライドされることに注意してください。 .. Warning:: カスタムプローブ設定がクラスターの操作要件と一致していることを確認して、意図しない中断を防ぎます。 .. NOTE:: プローブ構成の詳細については、 :ref:`probe API ` を参照してください。 たとえば、次の構成はデフォルトの動作をオーバーライドし、\ ``livenessProbeTimeout`` をバイパスします。 .. code:: yaml # ... snip spec: probes: liveness: periodSeconds: 3 timeoutSeconds: 3 failureThreshold: 10 Readiness Probe ^^^^^^^^^^^^^^^ Readiness Probeは、PostgreSQLインスタンスを実行しているポッドがトラフィックを受け入れ、要求を処理する準備ができているときを判断します。 CloudNativePGは、準備状況プローブに次のデフォルト構成を使用します。 .. code:: yaml failureThreshold: 3 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 5 デフォルト設定が要件に合わない場合は、 ``.spec.probes.readiness`` スタンザでパラメーターを指定して、readnessプローブを完全にカスタマイズできます。例 .. code:: yaml # ... snip spec: probes: readiness: periodSeconds: 3 timeoutSeconds: 3 failureThreshold: 10 .. Warning:: カスタムプローブ設定がクラスターの操作要件と一致していることを確認して、意図しない中断を防ぎます。 .. NOTE:: プローブの構成の詳細については、 :ref:`probe API ` を参照してください。 シャットダウン制御 ------------------ Postgresを実行しているポッドが手動で、またはノードドレイン操作に続いてKubernetesによって削除されると、kubeletはインスタンスマネージャーに終了信号を送信し、インスタンスマネージャーは適切な方法でPostgreSQLのシャットダウンを担当します。 ``.spec.smartShutdownTimeout`` および\ ``.spec.stopDelay`` オプションは秒単位であり、PostgreSQLがシャットダウンするまでの時間を制御します。値はデフォルトでそれぞれ180および1800秒です。 シャットダウン手順は2つの手順で構成されます。 1. インスタンスマネージャーは **スマート** シャットダウンを要求し、PostgreSQLへの新しい接続を禁止します。このステップは最大\ ``.spec.smartShutdownTimeout`` 秒間続きます。 2. PostgreSQLがまだアップしている場合、インスタンスマネージャーは **高速** シャットダウンを要求し、既存の接続を終了してすぐに終了します。インスタンスがWALファイルのアーカイブおよび/またはストリーミングを行っている場合、プロセスは\ ``.spec.stopDelay`` で設定された残り時間まで待機して操作が完了し、強制的にシャットダウンします。このようなタイムアウトは少なくとも15秒である必要があります。 .. Important:: データベース :ref:`PgBouncerPoolMode {postgresql-cnpg-io-v1-PgBouncerPoolMode} ` に影響を与えるPostgresクラスターでのデータの損失を回避するには、プライマリインスタンスが実行されているPodを削除しないでください。この場合、最初に別のインスタンスへのスイッチオーバーを実行します。 スイッチオーバー中のプライマリのシャットダウン ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ スイッチオーバー中のシャットダウン手順は、一般的な場合と少し異なります。実際、オペレーターは、新しいプライマリですべてのデータが利用できるように保証に、選択した新しいプライマリを昇格させる前に、元のプライマリに **fast** シャットダウンを発行する必要があります。 このため、秒単位で表される\ ``.spec.switchoverDelay`` は、元のプライマリが正常にシャットダウンし、すべてのWALファイルをアーカイブする時間を制御します。デフォルトでは、\ ``3600`` 1時間に設定されています。 .. Warning:: `.spec.switchoverDelay` オプションは :ref:`PgBouncerPoolMode {postgresql-cnpg-io-v1-PgBouncerPoolMode} ` に影響します とPostgreSQLデータベースの :ref:`RTOとRPOのインパクト ` 低い値に設定すると、RPOよりもRTOが優先される場合がありますが、クラスターレベルおよび/またはバックアップレベルでデータの損失が発生します。逆に、高い値に設定すると、スイッチオーバー中にアクティブなプライマリのないクラスターを長時間放置する間のデータ損失のリスクを取り除くことができます。 フェイルオーバー ---------------- プライマリポッドに障害が発生した場合、クラスターはフェールオーバーモードになります。詳細は :ref:`自動フェイルオーバー <自動フェイルオーバー>` を参照してください。 ディスクフル障害 ---------------- ストレージの枯渇は、PostgreSQLクラスターのよく知られた問題です。 `PostgreSQL documentation `_ では、考えられる障害シナリオと、ディスクの使用状況を監視してディスクがいっぱいになるのを防ぐことの重要性を強調しています。 同じことはCloudNativePGとKubernetesにも当てはまります。 :ref:`ClusterMonitoringTLSConfiguration {postgresql-cnpg-io-v1-ClusterMonitoringTLSConfiguration} ` WALセグメントが使用するディスク領域と、Prometheusにエクスポートされたディスク使用量の標準メトリックの確認に関する詳細を提供します。 .. Important:: 実稼働システムでは、データベースを継続的に監視することが重要です。ディスクストレージが使い果たされると、データベースサーバーがシャットダウンする場合があります。 .. Note:: 使い果たしたストレージの検出は、ディスクのサイズと使用状況を正確に報告するストレージクラスに依存しています。これは、KindのようなシミュレートされたKubernetes環境、または`csi-driver-host-path` などのテストストレージクラス実装には当てはまらない場合があります。 WALが含まれるディスクがいっぱいになり、これ以上WALセグメントを保存できなくなると、PostgreSQLは動作を停止します。 CloudNativePGは、次のWALセグメントを保存するための十分な領域があることを確認することにより、この問題を正しく検出し、復旧を複雑にする可能性のあるフェイルオーバーのトリガーを回避します。 これにより、人間の管理者は根本的な原因に対処できます。 このような場合、ストレージクラスでサポートされている場合、現在最も早いアクションは次のことです。 1. フルPVCのストレージサイズを拡張する 2. ``Cluster`` リソースのサイズを同じ値に増加します 問題が解決され、WALセグメント用の十分な空き領域が確保されると、ポッドが再起動し、クラスターが正常な状態になります。 ドキュメントの :ref:`ボリュームの拡張 <ボリュームの拡張>` も参照してください。