Postgres instance manager¶
CloudNativePGは、フェイルオーバー管理のために外部ツールに依存しませんAPIサーバーと Postgresインスタンスマネージャ と呼ばれるネイティブキーコンポーネントに単純に依存しています。
インスタンスマネージャは、PostgreSQLの主要なプロセス（ postmaster
とも呼ばれます）のライフサイクル全体を処理します。
新しいクラスターを作成すると、演算子はインスタンスごとにポッドを作成します。フィールド
.spec.instances は、作成するインスタンスの数を指定します。
各Podは、メインコンテナーの親プロセス（PID 1）としてインスタンスマネージャをスタートし、メインコンテナーはPostgreSQLインスタンスを実行します。 Podの有効期間中、インスタンスマネージャはliveness andreadiness probesをハンドルするバックエンドとして機能します。
活性と準備のプローブ¶
livenessプローブはプローブに依存していますが、readinessプローブはデータベースがリスタートしており、スーパーユーザー資格情報を使用して接続を受け入れることができるかどうかを確認します。
プローブコマンドが各チェック間に10秒インターバルで3回失敗すると、2つのプローブは失敗をレポートします。
現時点では、Kubernetes
1.17でのみ起動プローブが導入されているため、演算子はPodで
startupProbe を設定しません。
livenessプローブは、
PostgreSQLインスタンスが中断状態にあり、再起動ニーズがあるかどうかを検出するために使用されます。
startDelay
の値は、プローブの実行を遅らせるために使用されます。これは、スタートアップ時間が長いインスタンスの再起動を防ぐために使用されます。
ポッドが起動してからlivenessprobeが動作を開始するまでの秒数は、
.spec.startDelay
パラメータで表され、デフォルトは30秒です。クラスターの正しい値は、
PostgreSQLのスタートに必要な時間に関連しています。
.spec.startDelay が低すぎる場合、
PostgreSQLのスタートアップ前に活性プローブが動作をスタートし、Podが適切に再起動される可能性があります。
シャットダウン制御¶
Postgresを実行しているポッドが、手動またはノードドレインオペレーションに続いてKubernetesによって削除されると、kubeletはインスタンスマネージャに終了シグナルを送信し、インスタンスマネージャは適切な方法でPostgreSQLをシャットダウンします。は、 PostgreSQLがシャットダウンするまでの時間です。値のデフォルトは30秒です。
シャットダウンプロシージャは、2つのステップで構成されます。
1.インスタンスマネージャは スマート シャットダウンを要求し、
PostgreSQLへの新しい接続を許可しません。このステップは、
.spec.stopDelay で設定された時間の半分の間続きます。
PostgreSQLがまだ起動している場合、インスタンスマネージャは 高速 シャットダウンを要求し、既存の接続を終了してすぐに終了します。インスタンスがWALファイルをアーカイビングおよび/またはストリーミングしている場合、プロセスは残りの半分まで待機しますオペレーションを完了してから強制的にシャットダウンするために
.spec.stopDelayに設定された時間
重要
データベースのRPOに影響するPostgresクラスターのデータロスを回避オーダーに、プライマリインスタンスが実行されているポッドを削除しないでください。この場合、最初に別のインスタンスへのスイッチオーバーを実行します。
スイッチオーバー中のプライマリのシャットダウン¶
スイッチオーバー中のシャットダウンプロシージャは、一般的な場合とわずかに異なります。実際、演算子は、すべてのデータが新しいプライマリで利用できることを保証オーダーに、選択された新しいプライマリをプロモートする前に、前のプライマリが 高速 シャットダウンを発行することを要求します。
このため、秒単位で表される .spec.switchoverDelay
は、元のプライマリに適切にシャットダウンしてすべてのWALファイルをアーカイブするために与えられる時間を制御します。この時間フレームでは、プライマリインスタンスは接続を受け入れません。値のデフォルトは1年より大きい数秒で、無限の遅延をシミュレートし、データの耐久性を維持するのに十分な大きさ。
警告
.spec.switchoverDelay オプションは、 PostgreSQLデータベースのRPOとRTOに影響します。これを低い値に設定すると、RPOよりもRTOが優先されますが、クラスターレベルやバックアップレベルでデータロスれる可能性があります。それどころか、高い値に設定すると、スイッチオーバー中により長い時間アクティブなプライマリなしでクラスタを残しながら、データロスのリスクを取り除くことができます。
フェイルオーバー¶
プライマリポッドに障害が発生した場合、クラスターはフェイルオーバーモードになります。詳細については、 Automated failover を参照してください。
