Postgresインスタンスマネージャー ================================ CloudNativePGは、フェールオーバー管理に外部ツールに依存しません。これは、Kubernetes APIサーバーと、 **Postgresインスタンスマネージャー** と呼ばれるネイティブキーコンポーネントに依存するだけです。 インスタンスマネージャーは、PostgreSQL主要プロセス\ ``postmaster`` としても知られるライフサイクル全体を管理します。 新しいクラスターを作成すると、オペレーターはインスタンスごとにポッドを作成します。フィールド\ ``.spec.instances`` は、作成するインスタンスの数を指定します。 各ポッドは、メインコンテナの親プロセスPID 1としてインスタンスマネージャーを起動し、PostgreSQLインスタンスを実行します。ポッドのライフタイム中、インスタンスマネージャーはバックエンドとして機能して `startup, liveness and readiness probes `_ を処理します。 スタートアップ、活性、および準備状況プローブ -------------------------------------------- スタートアップとライブネスプローブは\ ``pg_isready`` に依存しますが、準備状況プローブは、データベースが稼働していて、スーパーユーザーの資格情報を使用して接続を受け入れることができるかどうかを確認します。 ポッドがトラフィックを受け入れる準備ができている場合、準備状況プローブはポジティブになります。 livenessプローブは、起動プローブ間隔が経過した後、コンテナを再起動するタイミングを制御します。 .. Important:: livenessプローブとreadnessプローブは、プローブコマンドが各チェックの間に10秒の間隔で3回失敗した場合に失敗を報告します。 livenessプローブは、PostgreSQLインスタンスが破損した状態にあり、再起動が必要かどうかを検出します。 ``startDelay`` の値は、プローブの実行を遅延するために使用され、起動時間の長いインスタンスが再起動されないようにします。 ポッドが起動してからlivenessプローブが動作を開始するまでの間隔秒単位は、 ``.spec.startDelay`` パラメーターで表されます。デフォルトは3600秒です。クラスターの正しい値は、PostgreSQLの起動に必要な時間に関連しています。 .. Warning:: `.spec.startDelay` が低すぎる場合、PostgreSQLの起動が完了する前にlivenessプローブは動作を開始し、Podが途中で再起動される可能性があります。 シャットダウン制御 ------------------ Postgresを実行しているポッドが手動で、またはノードドレイン操作に続いてKubernetesによって削除されると、kubeletはインスタンスマネージャーに終了信号を送信し、インスタンスマネージャーは適切な方法でPostgreSQLのシャットダウンを担当します。 ``.spec.smartShutdownTimeout`` および\ ``.spec.stopDelay`` オプションは秒単位であり、PostgreSQLがシャットダウンするまでの時間を制御します。値はデフォルトでそれぞれ180および1800秒です。 シャットダウン手順は2つの手順で構成されます。 1. インスタンスマネージャーは **スマート** シャットダウンを要求し、PostgreSQLへの新しい接続を禁止します。このステップは最大\ ``.spec.smartShutdownTimeout`` 秒間続きます。 2. PostgreSQLがまだアップしている場合、インスタンスマネージャーは **高速** シャットダウンを要求し、既存の接続を終了してすぐに終了します。インスタンスがWALファイルのアーカイブおよび/またはストリーミングを行っている場合、プロセスは\ ``.spec.stopDelay`` で設定された残り時間まで待機して操作が完了し、強制的にシャットダウンします。このようなタイムアウトは少なくとも15秒である必要があります。 .. Important:: データベースRPOに影響を与えるPostgresクラスターでのデータの損失を回避するために、プライマリインスタンスが実行されているポッドを削除しないでください。この場合、最初に別のインスタンスへのスイッチオーバーを実行します。 スイッチオーバー中のプライマリのシャットダウン ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ スイッチオーバー中のシャットダウン手順は、一般的な場合と少し異なります。実際、オペレーターは元のプライマリに発行することを必要とします。 - 新しいプライマリですべてのデータが利用できるように保証には、選択した新しいプライマリを昇格させる前に \*高速*\* シャットダウンします。 このため、秒単位で表される\ ``.spec.switchoverDelay`` は、元のプライマリが正常にシャットダウンし、すべてのWALファイルをアーカイブする時間を制御します。デフォルトでは、\ ``3600`` 1時間に設定されています。 .. Warning:: `.spec.switchoverDelay` オプションは、PostgreSQLデータベースのRPOおよびRTOに影響します。低い値に設定すると、RPOよりもRTOが優先される場合がありますが、クラスターレベルおよび/またはバックアップレベルでデータの損失が発生します。逆に、高い値に設定すると、スイッチオーバー中にアクティブなプライマリのないクラスターを長時間放置する間のデータ損失のリスクを取り除くことができます。 フェイルオーバー ----------------