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