Postgres Instance Manager ========================= .. raw:: html CloudNativePGは、フェールオーバー管理に外部ツールに依存しません。これは、Kubernetes APIサーバーと、 **Postgresインスタンスマネージャー** と呼ばれるネイティブキーコンポーネントに依存するだけです。 インスタンスマネージャーは、PostgreSQLサーバープロセス\ ``postmaster`` としても知られるライフサイクル全体を処理します。 新しいクラスターを作成すると、オペレーターはインスタンスごとにポッドを作成します。フィールド\ ``.spec.instances`` は、作成するインスタンスの数を指定します。 各ポッドは、メインコンテナの親プロセスPID 1としてインスタンスマネージャーを起動し、PostgreSQLインスタンスを実行します。ポッドのライフタイム中、インスタンスマネージャーはバックエンドとして機能して `startup, liveness and readiness probes `_ を処理します。 スタートアッププローブ ---------------------- 起動プローブは、PostgreSQLインスタンスがプライマリかスタンバイかにかかわらず、完全に起動していることを確認します。 .. Note:: デフォルトでは、起動プローブは `pg_isready `_ を使用します。ただし、別の起動戦略を指定することにより、動作をカスタマイズできます。 　 startupプローブの実行中、livenessプローブとreadnessプローブは無効のままです。 Kubernetes標準に従って、startupプローブが失敗すると、kubeletはコンテナを終了し、再起動します。 ``.spec.startDelay`` パラメーターは、startupプローブが成功するまでに許可される最大時間を秒単位で指定します。 デフォルトでは、\ ``startDelay`` は\ ``3600`` 秒に設定されます。特定の環境でPostgreSQLが完全に初期化する必要がある時間に基づいて、この設定を調整することをお勧めします。 .. Warning:: `.spec.startDelay` の設定が低すぎると、livenessプローブが途中でアクティブ化され、PostgreSQLが完全に初期化されていない場合は不必要なPodが再起動する可能性があります。 　 CloudNativePGは、次のデフォルトパラメーターを使用して起動プローブを構成します。 .. code:: yaml failureThreshold: FAILURE_THRESHOLD periodSeconds: 10 successThreshold: 1 timeoutSeconds: 5 ``failureThreshold`` 値は、 ``startDelay`` を\ ``periodSeconds`` で除算することにより自動的に計算されます。 構成の\ ``.spec.probes.startup`` セクションでプローブ設定をカスタマイズできます。 .. Warning:: カスタムプローブ設定がクラスターの操作要件に合わせて調整されていることを確認して、意図しない中断を回避します。 　 .. Note:: プローブ構成の詳細については、 :ref:`probe API documentation ` を参照してください。 　 ``.spec.probes.startup.failureThreshold`` を手動で指定すると、デフォルトの動作がオーバーライドされ、\ ``startDelay`` の自動使用が無効になります。 たとえば、次の構成は、 ``startDelay`` をバイパスして、カスタムプローブパラメーターを明示的に設定します。 .. code:: yaml ## ... 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`` が指定されない場合、レプリカはストリーミングを開始するとすぐに正常に開始されたとみなされます。 .. Note:: `.spec.probes.startup.maximumLag` オプションは、ポッドの起動フェーズ中にのみ検証および適用されます。つまり、レプリカが起動しているときにのみ適用されます。 　 .. Warning:: `maximumLag` オプションの構成が正しくない場合、startupプローブの継続的な失敗が発生し、レプリカの再起動が繰り返される場合があります。このオプションの動作を理解し、`failureThreshold` および`periodSeconds` の適切な値を構成して、レプリカがソースに追いつくのに十分な時間を与えます。 　 次の例では、レプリカが開始されたとみなされるソースからの最大16Miの遅延が必要です。 .. code:: yaml ## probes: startup: type: streaming maximumLag: 16Mi Liveness Probe -------------- livenessプローブは、startupプローブが正常に完了した後に開始されます。その主な役割は、PostgreSQLインスタンスマネージャーが正常に動作していることを確認することです。 Kubernetes標準に従って、livenessプローブが失敗すると、kubeletはコンテナを終了し、再起動します。 ポッドが生きていないとして分類されるまでの時間は、 ``.spec.livenessProbeTimeout`` パラメーターを介して構成できます。 CloudNativePGは、次のデフォルトパラメーターを使用してlivenessプローブを構成します。 .. code:: yaml failureThreshold: FAILURE_THRESHOLD periodSeconds: 10 successThreshold: 1 timeoutSeconds: 5 ``failureThreshold`` 値は、 ``livenessProbeTimeout`` を\ ``periodSeconds`` で除算することにより自動的に計算されます。 デフォルトでは、\ ``.spec.livenessProbeTimeout`` は\ ``30`` 秒に設定されます。これは、livenessプローブが、各チェックの間に10秒の間隔で、3回連続したプローブ障害を検出した場合に障害を報告することを意味します。 構成の\ ``.spec.probes.liveness`` セクションでプローブ設定をカスタマイズできます。 .. Warning:: カスタムプローブ設定がクラスターの操作要件に合わせて調整されていることを確認して、意図しない中断を回避します。 　 .. Note:: プローブ構成の詳細については、 :ref:`probe API documentation ` を参照してください。 　 ``.spec.probes.liveness.failureThreshold`` を手動で指定すると、デフォルトの動作がオーバーライドされ、\ ``livenessProbeTimeout`` の自動使用が無効になります。 たとえば、次の構成は、 ``livenessProbeTimeout`` をバイパスして、カスタムプローブパラメーターを明示的に設定します。 .. code:: yaml ## ... snip spec: probes: liveness: periodSeconds: 3 timeoutSeconds: 3 failureThreshold: 10 プライマリ分離 ^^^^^^^^^^^^^^ CloudNativePG 1.27では、PostgreSQLプライマリの活性プローブの追加動作を導入し、次の条件の **両方** が満たされる場合に障害を報告します。 1. インスタンスマネージャーはKubernetes APIサーバーに到達できません 2. インスタンスマネージャーは、インスタンスマネージャーのREST APIを介して **他の** インスタンスに到達できません この動作の効果は、分離されたプライマリが生きていないと考えられ、その後、livenessプローブが失敗したときに **シャットダウン** します。 **デフォルトで有効になっています** 。以下を追加して無効にできます。 .. code:: yaml spec: probes: liveness: isolationCheck: enabled: false .. Note:: デフォルトのlivenessプローブ設定`livenessProbeTimeout` から自動的に派生は、アグレッシブな30秒になる場合があることに注意してください。そのため、環境に合わせてlivenessプローブ構成を明示的に設定することをお勧めします。 　 また、仕様は2つのオプションのネットワーク設定\ ``requestTimeout`` および\ ``connectionTimeout`` も受け入れます。どちらもデフォルトで\ ``1000`` ミリ秒単位です。クラウド環境では、これらの値を増やす必要がある場合があります。例 .. code:: yaml spec: probes: liveness: isolationCheck: enabled: true requestTimeout: "2000" connectionTimeout: "2000" Readiness Probe --------------- スタートアッププローブが正常に完了すると、準備状況プローブが開始されます。その主な目的は、PostgreSQLインスタンスがポッドのライフサイクル中の任意の時点でトラフィックを受け入れ、要求を処理する準備ができているかどうかを確認することです。 .. Note:: デフォルトでは、準備状況プローブは `pg_isready `_ を使用します。ただし、別の準備状況戦略を指定することにより、動作をカスタマイズできます。 　 Kubernetes標準に従って、準備状況プローブが失敗した場合、ポッドは未準備としてマークされ、どのサービスからトラフィックを受信しません。準備ができていないポッドは、自動フェイルオーバーシナリオ中のプロモーションの対象外です。 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 ` を参照してください。 　 Readness Probe戦略 ^^^^^^^^^^^^^^^^^^ 特定のシナリオでは、クラスターの準備状況戦略をカスタマイズする必要がある場合があります。たとえば、プライマリからストリーミングを開始するまでレプリカの準備ができていることのマーキングを遅らせるか、レプリカの準備ができていると判断する前に最大レプリケーションラグしきい値を定義できます。 これらの要件に対応するために、CloudNativePGは2つのオプショナルパラメーター\ ``type`` および\ ``maximumLag`` で\ ``.spec.probes.readiness`` スタンザを拡張しました。 :ref:`スタートアッププローブ戦略 <スタートアッププローブ戦略>` を参照してください。 これらのオプションの詳細については、セクションを参照してください。 .. Note:: startupプローブとは異なり、 `.spec.probes.readiness.maximumLag` オプションは継続的に監視されます。この設定が適切に調整されていない場合、遅延レプリカの準備ができなくなる場合があります。 　 .. Warning:: `maximumLag` オプションの誤った構成は、readinessプローブの失敗を繰り返して、次のような重大な結果を引き起こす可能性があります。 - フェールオーバー中のプロモーションまたは同期レプリケーションクォーラムへの参加など、キーオペレーター機能からのレプリカの除外。 - 読み取り/読み取り専用サービスの中断。 - フェールオーバー時間が長いシナリオでは、レプリカの準備ができていないと宣言され、手動介入が必要なクラスターストールが発生する場合があります。 　 .. Note:: `streaming` および`maximumLag` オプションは非常に注意して使用します。 PostgreSQLレプリケーションに慣れていない場合は、デフォルトの戦略を使用してください。不明な場合は、専門家のアドバイスを求めてください。 　 次の例では、レプリカが準備ができているとみなされるように、ソースからの最大64Miの遅延が必要です。また、起動プローブが成功するまでに約300秒30失敗×10秒もかかります。 .. code:: yaml ## probes: readiness: type: streaming maximumLag: 64Mi failureThreshold: 30 periodSeconds: 10 シャットダウン制御 ------------------ Postgresを実行しているポッドが手動で、またはノードドレイン操作に続いてKubernetesによって削除されると、kubeletはインスタンスマネージャーに終了信号を送信し、インスタンスマネージャーは適切な方法でPostgreSQLのシャットダウンを担当します。 ``.spec.smartShutdownTimeout`` および\ ``.spec.stopDelay`` オプションは秒単位であり、PostgreSQLがシャットダウンするまでの時間を制御します。値はデフォルトでそれぞれ180および1800秒です。 シャットダウン手順は2つの手順で構成されます。 1. インスタンスマネージャーは、最初に\ ``CHECKPOINT`` を発行し、次に **スマート** シャットダウンを開始し、PostgreSQLへの新しい接続を禁止します。このステップは最大\ ``.spec.smartShutdownTimeout`` 秒間続きます。 2. PostgreSQLがまだアップしている場合、インスタンスマネージャーは **高速** シャットダウンを要求し、既存の接続を終了してすぐに終了します。インスタンスがWALファイルのアーカイブおよび/またはストリーミングを行っている場合、プロセスは\ ``.spec.stopDelay`` で設定された残り時間まで待機して操作が完了し、強制的にシャットダウンします。このようなタイムアウトは少なくとも15秒である必要があります。 .. Note:: データベース :ref:`PgBouncerPoolMode ` に影響を与えるPostgresクラスターでのデータの損失を回避するには、プライマリインスタンスが実行されているポッドを削除しないでください。この場合、最初に別のインスタンスへのスイッチオーバーを実行します。 　 スイッチオーバー中のプライマリのシャットダウン ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ スイッチオーバー中のシャットダウン手順は、一般的な場合と少し異なります。元のプライマリのインスタンスマネージャーは、最初に\ ``CHECKPOINT`` を発行し、指定された新しいプライマリが昇格する前にPostgreSQLの **高速** シャットダウンを開始し、新しいプライマリですべてのデータが安全に利用できるようにします。 このため、秒単位で表される\ ``.spec.switchoverDelay`` は、元のプライマリが正常にシャットダウンし、すべてのWALファイルをアーカイブする時間を制御します。デフォルトでは、\ ``3600`` 1時間に設定されています。 .. Warning:: `.spec.switchoverDelay` オプションは :ref:`PgBouncerPoolMode ` に影響します とPostgreSQLデータベースの :ref:`バックアップ頻度とRTO <バックアップ頻度とRTO>` 低い値に設定すると、RPOよりもRTOが優先される場合がありますが、クラスターレベルおよび/またはバックアップレベルでデータの損失が発生します。逆に、高い値に設定すると、スイッチオーバー中にアクティブなプライマリのないクラスターを長時間放置する間のデータ損失のリスクを取り除くことができます。 　 フェイルオーバー ---------------- プライマリポッドに障害が発生した場合、クラスターはフェールオーバーモードになります。詳細は :ref:`FailoverQuorum ` を参照してください。 ディスクフル障害 ---------------- ストレージの枯渇は、PostgreSQLクラスターのよく知られた問題です。 `PostgreSQL documentation `_ では、考えられる障害シナリオと、ディスクの使用状況を監視してディスクがいっぱいになるのを防ぐことの重要性を強調しています。 同じことはCloudNativePGとKubernetesにも当てはまります。 :ref:`バックアップの進行状況のモニタリング <バックアップの進行状況のモニタリング>` WALセグメントが使用するディスク領域と、Prometheusにエクスポートされたディスク使用量の標準メトリックの確認に関する詳細を提供します。 .. Note:: 実稼働システムでは、データベースを継続的に監視することが重要です。ディスクストレージが使い果たされると、データベースサーバーがシャットダウンする場合があります。 　 .. Note:: 使い果たしたストレージの検出は、ディスクのサイズと使用状況を正確に報告するストレージクラスに依存しています。これは、KindのようなシミュレートされたKubernetes環境、または`csi-driver-host-path` などのテストストレージクラス実装には当てはまらない場合があります。 　 WALが含まれるディスクがいっぱいになり、これ以上WALセグメントを保存できなくなると、PostgreSQLは動作を停止します。 CloudNativePGは、次のWALセグメントを保存するための十分な領域があることを確認することにより、この問題を正しく検出し、復旧を複雑にする可能性のあるフェイルオーバーのトリガーを回避します。 これにより、人間の管理者は根本的な原因に対処できます。 このような場合、ストレージクラスでサポートされている場合、現在最も早いアクションは次のことです。 1. フルPVCのストレージサイズを拡張する 2. ``Cluster`` リソースのサイズを同じ値に増加します 問題が解決され、WALセグメント用の十分な空き領域が確保されると、ポッドが再起動し、クラスターが正常な状態になります。 ドキュメントの :ref:`ボリュームの拡張 <ボリュームの拡張>` も参照してください。