故障モード¶
このセクションでは、PostgreSQLがその存続期間中にKubernetesクラスターで直面する可能性のある主要な障害シナリオの概要を提供します。
重要
発生している障害シナリオがこのセクションで説明されていない場合は、すぐにEDBに連絡してサポートと支援を受けてください。
詳細については、CloudNativePGによって実装されるlivenessプローブとreadinessプローブを参照してください。
ストレージスペースの使用量¶
オペレーターは、PostgreSQLインスタンスごとに1つのPVCをインスタンス化して、
PGDATA コンテンツを保存します。クラスターの初期化中に
.spec.walStorage
が指定された場合、WALストレージ専用の2番目のPVCがプロビジョニングされます。
このようなストレージスペースは、次の2つの場合に再利用のために設定されます。
対応するPodがユーザーによって削除されたとき（そして新しいPodが再作成されます）
対応するPodが削除され、別のノードでスケジュールされたとき
オペレータが特定の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コンテナのreadinessプローブが失敗します。postgresコンテナの活性プローブが失敗します。Kubernetesワーカーノードがドレインされます。
ポッドがスケジュールされているKubernetesワーカーノードに障害が発生します。
これらの障害はそれぞれ、 Cluster
とオペレーターが管理するサービスにさまざまな影響を与えます。
ユーザーによって削除されたポッド¶
オペレーターに削除が通知されます。 Cluster
に属する新しいポッドは、既存のPVCが利用可能な場合は再利用して、それ以外の場合は
プライマリ の物理バックアップから自動的に作成されます。
重要
Podを意図的に削除する場合、 PodDisruptionBudget ポリシーは強制されません。
自己修復は、 apiserver 通知されるとすぐに行われます。
Readinessプローブの失敗¶
3回失敗すると、ポッドは 準備ができていない
と見なされます。ポッドは引き続きCluster
の一部であり、新しいポッドは作成されません。
失敗の原因を修正できない場合は、ポッドを手動で削除できます。それ以外の場合、ポッドは、障害が解決したときに前のロールを再開します。
プローブが3回失敗すると、自己修復が発生します。
Livenessプローブの失敗¶
3回失敗すると、 postgres
コンテナーは失敗したと見なされます。ポッドは引き続きCluster
の一部であり、 kubelet
はコンテナを再起動しようとします。失敗の原因を修正できない場合は、ポッドを手動で削除できます。
プローブが3回失敗すると、自己修復が発生します。
ワーカーノードがドレインされました¶
ポッドはワーカーノードから削除され、サービスから削除されます。
nodeMaintenanceWindow パラメーターのreusePVC
オプションがoff に設定されている場合、新しいポッドは プライマリ
の物理バックアップとは異なるワーカーノードに作成されます（デフォルト：メンテナンスウィンドウ中はon
、それ以外の場合はoff ）。
PodDisruptionBudget
は、準備ができていない少なくとも別のポッドがある場合、ポッドがエビクトされるのを妨げる場合があります。
注釈
reusePVC が`false` に設定されている場合、シングルインスタンスクラスターはノードのドレインを防ぎます。 Kubernetes Upgrade section を参照してください。
自己修復は、 apiserver 通知されるとすぐに行われます。
ワーカーノードの障害¶
ノードに障害が発生したため、 kubelet はlivenessプローブとreadinessプローブを実行しません。ポッドは、その特定の障害の原因に対してKubernetesクラスター管理者が構成した容認秒後に、削除のマークが付けられます。 Kubernetesクラスターの構成方法によっては、ポッドが以前にサービスから削除される場合があります。
プライマリ の物理バックアップとは異なるワーカーノードに新しいポッドが作成されます。 Kubernetesクラスターでのそのパラメーターのデフォルト値は5分です。
tolerationSeconds の後に自己修復が行われます。
自己治癒¶
障害が発生したポッドがスタンバイの場合、ポッドは -r サービスおよび
-ro
サービスから削除されます。次に、ポッドは、使用可能な場合はそのPVCを使用して再起動されます。それ以外の場合、新しいポッドは現在のプライマリのバックアップから作成されます。ポッドは、準備ができたら、
-r サービスと-ro サービスに再度追加されます。
障害が発生したポッドがプライマリの場合、オペレーターはアクティブなポッドを準備完了ステータスと最小のレプリケーションラグで昇格させ、
-rw サービスをポイントします。障害が発生したポッドは、 -r
サービスおよび-rw
サービスから削除されます。他のスタンバイは、新しいプライマリからの複製を開始します。元のプライマリは、
pg_rewind
を使用して、PVCが利用可能な場合、新しいプライマリと同期します。そうしないと、現在のプライマリのバックアップから新しいスタンバイが作成されます。
手動介入¶
文書化されていない障害の場合、手動で問題を解決するために介入する必要がある場合があります。
重要
このような場合、EDBエンジニアリングチームのサポートと支援なしに手動操作を実行しないでください。
オペレーターのバージョン1.11.0以降、次のように
cnpg.io/reconciliationLoop
アノテーションを使用して、選択したPostgreSQLクラスターで調整ループを一時的に無効にすることができます。
metadata:
name: cluster-example-no-reconcile
annotations:
cnpg.io/reconciliationLoop: "disabled"
spec:
# ...
cnpg.io/reconciliationLoop
は、細心の注意を払って、異常/緊急操作の唯一の期間中に使用する必要があります。
警告
このアノテーションは限られた期間のみ使用し、緊急事態が終了したら削除してください。このアノテーションをクラスターに残すと、オペレーターはフェールオーバーなどの自己修復オペレーションを発行できなくなります。
