障害モード¶
このセクションでは、PostgreSQLがその存続期間中にKubernetesクラスターで直面する可能性のある主要な障害シナリオの概要を提供します。
重要
発生している障害シナリオがこのセクションで説明されていない場合、サポートと支援についてはすぐにEDBに連絡してください。
ストレージ使用量¶
オペレーターは、PostgreSQLインスタンスごとに1つのPVCをインスタンス化して、
PGDATA コンテンツを保存します。
このようなストレージ領域は、次の2つの場合に再利用のために設定されます。
対応するPodがユーザーによって削除された場合（および新しいPodが再作成されます）
対応するPodが削除され、別のノードでスケジュールされたとき
オペレータが特定のPVCを再利用しないようにするには、ポッドを削除する前にPVCを削除する必要があります。このために、次のコマンドを使用できます。
kubectl delete -n [namespace] pvc/[cluster-name]-[serial] pod/[cluster-name]-[serial]
例：
$ kubectl delete -n default pvc/cluster-example-1 pod/cluster-example-1
persistentvolumeclaim "cluster-example-1" 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 コンテナは失敗したと見なされます。
Podは引き続き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 サービスに再度追加されます。
障害が発生したポッドがプライマリの場合、オペレーターはステータスが ready
でレプリケーションラグが最小のアクティブなポッドを昇格させ、 -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
は、細心の注意を払って、臨時/緊急操作の唯一の期間に使用する必要があります。
警告
このアノテーションは限られた期間のみ使用し、緊急事態が終了したら削除してください。このアノテーションをクラスターに残すと、オペレーターがフェールオーバーなどの自己修復オペレーションを発行できなくなります。
