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