障害モード
このセクションでは、PostgreSQLがその有効期間中にKubernetesクラスターで直面する可能性のある主要な障害シナリオの概要を提供します。
重要
発生している障害シナリオがこのセクションでカバーされていない場合、すぐに professional support を探してください。
参考
Postgresインスタンスマネージャー を参照してください。
CloudNativePGによって実装されるlivenessプローブとreadnessプローブの詳細については、 を参照してください。
ストレージ領域の使用量
オペレーターは、PostgreSQLインスタンスごとに1つのPVCをインスタンス化して、PGDATA
コンテンツを保存します。クラスターの初期化中に.spec.walStorage
が指定された場合、WALストレージ専用の2番目のPVCがプロビジョニングされます。
このような記憶領域は、2つの場合に再利用のために設定されます。
対応するポッドがユーザーによって削除され、新しいポッドが再作成されるとき
対応するポッドが削除され、別のノードでスケジュールされたとき
オペレーターが特定のPVCを再利用したくない場合は、ポッドを削除する前にPVCを削除する必要があります。このために、次のコマンドを使用できます。
kubectl delete -n [namespace] pvc/[cluster-name]-[serial] pod/[cluster-name]-[serial]
注釈
専用のWALボリュームを指定した場合、このプロセス中に削除する必要があります。
kubectl delete -n [namespace] pvc/[cluster-name]-[serial] pvc/[cluster-name]-[serial]-wal pod/[cluster-name]-[serial]
例
$ kubectl delete -n default pvc/cluster-example-1 pvc/cluster-example-1-wal pod/cluster-example-1
persistentvolumeclaim "cluster-example-1" deleted
persistentvolumeclaim "cluster-example-1-wal" deleted
pod "cluster-example-1" deleted
障害モード
Cluster に属するポッドは、次の方法で障害が発生する場合があります。
ポッドはユーザーによって明示的に削除されます。
postgresコンテナの準備状況プローブは失敗します。postgresコンテナのlivenessプローブは失敗します。Kubernetesワーカーノードはドレインされます。
ポッドがスケジュールされているKubernetesワーカーノードに障害が発生します。
これらの障害はそれぞれ、Cluster
およびオペレーターが管理するサービスにさまざまな影響を与えます。
ユーザーによって削除されたポッド
オペレーターに削除が通知されます。 Cluster
に属する新しいポッドは、既存のPVCがある場合は再利用して、それ以外の場合は
プライマリ の物理バックアップから開始して自動的に作成されます。
重要
ポッドを意図的に削除した場合、PodDisruptionBudget ポリシーは適用されません。
自己修復は、 apiserver に通知されるとすぐに発生します。
次の汎用コマンドを使用して、クラスターの特定のポッドで突然の障害をトリガーできます。
kubectl delete -n [namespace] \
pod/[cluster-name]-[serial] --grace-period=1
たとえば、プライマリで実際の障害をシミュレートし、フェールオーバープロセスをトリガーする場合は、次を実行できます。
kubectl delete pod [primary pod] --grace-period=1
警告
PostgreSQLクラスターで誤解を招く結果を生成する可能性があるため、フェールオーバーシミュレーションテストでは`--grace-period=0` を決して使用しないでください。猶予期間0は、実際の障害が発生した場合に何が起こるかとは逆に、postgres コンテナインスタンスマネージャーのPID 1プロセスがシャットダウンしていることを最初に確認せずに、ポッドがKubernetes APIサーバーからすぐに削除されることを保証します例 電源コードケーブルまたはネットワークパーティショニングを取り外します。その結果、オペレーターはプライマリのポッドを認識せず、プライマリがシャットダウンされた保証なしで、最も調整されたスタンバイをプロモーションするフェールオーバーをトリガーします。
Readinessプローブの失敗
3回失敗すると、ポッドは 準備ができていない
とみなされます。ポッドはCluster
の一部のままで、新しいポッドは作成されません。
障害の原因を修正できない場合は、ポッドを手動で削除できます。それ以外の場合、ポッドは、障害が解決されたときに以前のロールを再開します。
自己修復は、プローブが3回失敗すると発生します。
Livenessプローブの障害
3回障害が発生すると、postgres
コンテナは障害が発生したとみなされます。ポッドはCluster
の一部であり、 kubelet
はコンテナを再起動しようとします。障害の原因を修正できない場合は、ポッドを手動で削除できます。
自己修復は、プローブが3回失敗すると発生します。
ワーカーノードがドレインされました
ポッドはワーカーノードから削除され、サービスから削除されます。
nodeMaintenanceWindow パラメーターのreusePVC
オプションがoff に設定されている場合、新しいポッドは プライマリ
の物理バックアップから別のワーカーノードに作成されます。デフォルトメンテナンス時間帯はon
、それ以外の場合はoff 。
PodDisruptionBudget
は、準備ができていない少なくとも別のポッドが存在する場合、ポッドのエビクトを防止する場合があります。
注釈
reusePVC が`false` に設定されている場合、単一インスタンスクラスターはノードのドレインを防止します。 Kubernetes Upgrade section を参照してください。
自己修復は、 apiserver に通知されるとすぐに発生します。
ワーカーノードの障害
ノードに障害が発生しているため、 kubelet はlivenessプローブとreadnessプローブを実行しません。ポッドは、その特定の障害原因に対してKubernetesクラスター管理者が構成した許容秒後、削除用にマークされます。 Kubernetesクラスターの構成に基づいて、ポッドはサービスから以前に削除される場合があります。
新しいポッドは、 プライマリ の物理バックアップから別のワーカーノードに作成されます。 Kubernetesクラスターにおけるそのパラメーターのデフォルト値は5分です。
自己修復はtolerationSeconds の後に発生します。
自己修復
障害が発生したポッドがスタンバイの場合、ポッドは-r
サービスおよび-ro
サービスから削除されます。ポッドは、可能な場合はPVCを使用して再起動されます。それ以外の場合、新しいポッドは、現在のプライマリのバックアップから作成されます。準備ができたら、ポッドは-r
サービスと-ro サービスに再度追加されます。
障害が発生したポッドがプライマリの場合、オペレーターはステータスが準備ができており、レプリケーションラグが最も低いアクティブなポッドをプロモートし、
-rw サービスをそこにポイントします。障害が発生したポッドは、-r
サービスおよび-rw
サービスから削除されます。他のスタンバイは、新しいプライマリからの複製を開始します。元のプライマリは、PVCが利用可能な場合、
pg_rewind
を使用して新しいプライマリと自分自身を同期します。それ以外の場合、現在のプライマリのバックアップから新しいスタンバイが作成されます。
手動介入
文書化されていない障害の場合、介入して問題を手動で解決する必要がある場合があります。
重要
このような場合、 professional support なしで手動操作を実行しないでください。
オペレーターのバージョン1.11.0から、次のようにcnpg.io/reconciliationLoop
アノテーションを使用して、選択したPostgreSQLクラスターでリコンシリエーションループを一時的に無効にすることができます。
metadata:
name: cluster-example-no-reconcile
annotations:
cnpg.io/reconciliationLoop: "disabled"
spec:
# ...
cnpg.io/reconciliationLoop
は、特別な/緊急操作の期間のみに、細心の注意を払って使用する必要があります。
警告
このアノテーションは限定的な期間のみ使用し、緊急事態が終了したら削除するようにしてください。このアノテーションをクラスターに残すと、オペレーターはフェールオーバーなどの自己修復操作を発行できません。