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でのみ導入されているため、オペレーターはPodでstartupProbe
を構成しません。
liveness
probeは、PostgreSQLインスタンスが壊れた状態であり、再起動が必要かどうかを検出するために使用されます。
startDelay
の値は、プローブの実行を遅延させるために使用され、起動時間が長いインスタンスが再起動されないようにするために使用されます。
Podが起動してからlivenessプローブが動作を開始するまでの秒数は、
.spec.startDelay
パラメーターで表され、デフォルトは30秒です。クラスターの正しい値は、PostgreSQLの起動に必要な時間に関連しています。
.spec.startDelay
が低すぎる場合、livenessプローブはPostgreSQLの起動前に動作を開始し、Podが不適切に再起動される可能性があります。
シャットダウン制御¶
Postgresを実行しているPodが手動またはノードのドレイン操作に従ってKubernetesによって削除されると、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が優先される場合がありますが、クラスターレベルおよび/またはバックアップレベルでデータが失われます。逆に、これを高い値に設定すると、データ損失のリスクが排除され、スイッチオーバー中にアクティブなプライマリなしでクラスターが長時間離れなくなります。
フェイルオーバー¶
プライマリポッドに障害が発生した場合、クラスターはフェールオーバーモードになります。詳細は 自動フェイルオーバー を参照。
