Postgresインスタンスマネージャー

CloudNativePGは、フェールオーバー管理に外部ツールに依存しません。これは、Kubernetes APIサーバーと、 Postgresインスタンスマネージャー と呼ばれるネイティブキーコンポーネントに依存するだけです。

インスタンスマネージャーは、PostgreSQL主要プロセスpostmaster としても知られるライフサイクル全体を管理します。

新しいクラスターを作成すると、オペレーターはインスタンスごとにポッドを作成します。フィールド.spec.instances は、作成するインスタンスの数を指定します。

各ポッドは、メインコンテナの親プロセスPID 1としてインスタンスマネージャーを起動し、PostgreSQLインスタンスを実行します。ポッドのライフタイム中、インスタンスマネージャーはバックエンドとして機能して

startup, liveness and readiness probes を処理します。

スタートアップ、活性、および準備状況プローブ

スタートアップとライブネスプローブはpg_isready に依存しますが、準備状況プローブは、データベースが稼働していて、スーパーユーザーの資格情報を使用して接続を受け入れることができるかどうかを確認します。

ポッドがトラフィックを受け入れる準備ができている場合、準備状況プローブはポジティブになります。 livenessプローブは、起動プローブ間隔が経過した後、コンテナを再起動するタイミングを制御します。

重要

livenessプローブとreadnessプローブは、プローブコマンドが各チェックの間に10秒の間隔で3回失敗した場合に失敗を報告します。

livenessプローブは、PostgreSQLインスタンスが破損した状態にあり、再起動が必要かどうかを検出します。 startDelay の値は、プローブの実行を遅延するために使用され、起動時間の長いインスタンスが再起動されないようにします。

ポッドが生きていないとして分類されるまでに必要な時間は、 .spec.livenessProbeTimeout パラメーターで構成できます。デフォルトは30秒です。

ポッドが起動してからlivenessプローブが動作を開始するまでの間隔秒単位は、 .spec.startDelay パラメーターで表されます。デフォルトは3600秒です。クラスターの正しい値は、PostgreSQLの起動に必要な時間に関連しています。

警告

.spec.startDelay が低すぎる場合、PostgreSQLの起動が完了する前にlivenessプローブは動作を開始し、Podが途中で再起動される可能性があります。

シャットダウン制御

Postgresを実行しているポッドが手動で、またはノードドレイン操作に続いてKubernetesによって削除されると、kubeletはインスタンスマネージャーに終了信号を送信し、インスタンスマネージャーは適切な方法でPostgreSQLのシャットダウンを担当します。 .spec.smartShutdownTimeout および.spec.stopDelay オプションは秒単位であり、PostgreSQLがシャットダウンするまでの時間を制御します。値はデフォルトでそれぞれ180および1800秒です。

シャットダウン手順は2つの手順で構成されます。

インスタンスマネージャーは スマート シャットダウンを要求し、PostgreSQLへの新しい接続を禁止します。このステップは最大.spec.smartShutdownTimeout 秒間続きます。
PostgreSQLがまだアップしている場合、インスタンスマネージャーは高速シャットダウンを要求し、既存の接続を終了してすぐに終了します。インスタンスがWALファイルのアーカイブおよび/またはストリーミングを行っている場合、プロセスは.spec.stopDelay で設定された残り時間まで待機して操作が完了し、強制的にシャットダウンします。このようなタイムアウトは少なくとも15秒である必要があります。

重要

データベースRPOに影響を与えるPostgresクラスターでのデータの損失を回避するために、プライマリインスタンスが実行されているポッドを削除しないでください。この場合、最初に別のインスタンスへのスイッチオーバーを実行します。

スイッチオーバー中のプライマリのシャットダウン

スイッチオーバー中のシャットダウン手順は、一般的な場合と少し異なります。実際、オペレーターは、新しいプライマリですべてのデータが利用できるように保証に、選択した新しいプライマリを昇格させる前に、元のプライマリに fast シャットダウンを発行する必要があります。

このため、秒単位で表される.spec.switchoverDelay は、元のプライマリが正常にシャットダウンし、すべてのWALファイルをアーカイブする時間を制御します。デフォルトでは、3600 1時間に設定されています。

警告

.spec.switchoverDelay オプションは、PostgreSQLデータベースのRPOおよびRTOに影響します。低い値に設定すると、RPOよりもRTOが優先される場合がありますが、クラスターレベルおよび/またはバックアップレベルでデータの損失が発生します。逆に、高い値に設定すると、スイッチオーバー中にアクティブなプライマリのないクラスターを長時間放置する間のデータ損失のリスクを取り除くことができます。

フェイルオーバー

プライマリポッドに障害が発生した場合、クラスターはフェールオーバーモードになります。詳細は自動フェイルオーバーを参照してください。

ディスクフル障害

ストレージの枯渇は、PostgreSQLクラスターのよく知られた問題です。: PostgreSQL documentation

では、考えられる障害シナリオと、ディスクの使用状況を監視してディスクがいっぱいになるのを防ぐことの重要性を強調しています。

同じことはCloudNativePGとKubernetesにも当てはまります。 ClusterMonitoringTLSConfiguration {postgresql-cnpg-io-v1-ClusterMonitoringTLSConfiguration}

WALセグメントが使用するディスク領域と、Prometheusにエクスポートされたディスク使用量の標準メトリックの確認に関する詳細を提供します。

重要

実稼働システムでは、データベースを継続的に監視することが重要です。ディスクストレージが使い果たされると、データベースサーバーがシャットダウンする場合があります。

注釈

使い果たしたストレージの検出は、ディスクのサイズと使用状況を正確に報告するストレージクラスに依存しています。これは、KindのようなシミュレートされたKubernetes環境、または`csi-driver-host-path` などのテストストレージクラス実装には当てはまらない場合があります。

WALが含まれるディスクがいっぱいになり、これ以上WALセグメントを保存できなくなると、PostgreSQLは動作を停止します。 CloudNativePGは、次のWALセグメントを保存するための十分な領域があることを確認することにより、この問題を正しく検出し、復旧を複雑にする可能性のあるフェイルオーバーのトリガーを回避します。

これにより、人間の管理者は根本的な原因に対処できます。

このような場合、ストレージクラスでサポートされている場合、現在最も早いアクションは次のことです。

フルPVCのストレージサイズを拡張する
Cluster リソースのサイズを同じ値に増加します

問題が解決され、WALセグメント用の十分な空き領域が確保されると、ポッドが再起動し、クラスターが正常な状態になります。

ドキュメントのボリュームの拡張も参照してください。