Failure Modes¶
このセクションでは、PostgreSQLが存続期間中にKubernetesクラスターで直面する可能性があるメジャー障害シナリオの概要を説明します。
重要
発生している障害シナリオがこのセクションでカバーされていない場合は、すぐにサポートと支援のためにEDBに連絡してください。
ストレージスペースの使用¶
演算子は、 PostgreSQLインスタンスごとに1つのPVCをインスタンス化して、
PGDATA コンテンツを格納します。
このようなストレージスペースは、次の2つの場合に再利用できるように設定されています。
対応するポッドがユーザによって削除された場合（および新しいポッドが再作成されます）
対応するポッドが別のノードで削除およびスケジュールされる場合
演算子が特定のPVCを再利用できないようにするには、Podを削除する前に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
コンテナのレディネスプローブが失敗します。 * postgres
コンテナの活性プローブが失敗します。 *
Kubernetesワーカーノードが排出されました。
*ポッドがスケジュールされているKubernetesワーカーノードは失敗します。
これらの各障害は、 Cluster
および演算子が管理するサービスに異なる影響を及ぼします。
ユーザによって削除されたポッド¶
演算子に削除が通知されます。 the Cluster
に属する新しいポッドは、存在する場合は既存のPVCを再利用するか、そうでない場合は*
プライマリ *の物理的バックアップから開始して自動的に作成されます。
重要
ポッドを意図的に削除する場合、 PodDisruptionBudget ポリシーは適用されません。
apiserver *に通知されるとすぐに、自己修復が行われます。
準備プローブの失敗¶
3回失敗すると、ポッドは「準備ができていません」と見なされます。ポッドは引き続き
Cluster のパートであり、新しいポッドは作成されません。
失敗の原因を修正できない場合は、ポッドを手動で削除することができます。そうでない場合、障害が解決されると、ポッドは以前のロールを再開します。
プローブが3回失敗すると、自己修復が発生します。
活性プローブの失敗¶
3回失敗すると、 postgres
コンテナは失敗したと見なされます。ポッドは依然として Cluster
のパートであり、* kubelet
*はコンテナを再起動しようとします。失敗の原因を修正できない場合は、ポッドを手動で削除することができます。
プローブが3回失敗すると、自己修復が発生します。
ドレインされたワーカーノード¶
ポッドはワーカーノードから削除され、サービスから削除されます。
nodeMaintenanceWindow パラメーターの reusePVC オプションが
off に設定されている場合（デフォルト：メンテナンス期間中は on
、それ以外の場合は off
）、プライマリの物理的バックアップとは別のワーカーノードに新しいポッドが作成されます。
PodDisruptionBudget
は、準備ができていない別のポッドが少なくとも1つある場合、ポッドが削除されないようにします。
注釈
reusePVC が false に設定されている場合、シングルインスタンスクラスターはノードドレインを防ぎます。 Kubernetes Upgrade section を参照してください。
apiserver *に通知されるとすぐに、自己修復が行われます。
ワーカーノードの障害¶
ノードに障害が発生したため、* kubelet *は活性プローブと準備プローブを実行しません。その特定の障害原因に対してKubernetesクラスター管理者が設定した許容秒数後に、ポッドは削除対象としてマークされます。 Kubernetesクラスターの構成方法に基づいて、ポッドは以前にサービスから削除される場合があります。
新しいポッドは、プライマリの物理的バックアップとは異なるワーカーノードに作成されます。 Kubernetesclusterのそのパラメータのデフォルト値は5分です。
tolerationSeconds の後に自己修復が行われます。
自己修復¶
失敗したポッドがスタンバイの場合、ポッドは -r サービスおよび -ro
サービスから削除されます。ポッドは、使用可能な場合はそのPVCを使用して再起動されます。そうでない場合、現在のプライマリのバックアップからnewpodが作成されます。ポッドは、準備ができたら
-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
は、特別な操作や緊急オペレーションの期間中は細心の注意を払って使用する必要があります。
警告
限られた期間のみこのアノテーションを使用し、緊急事態が終了したら削除makeようにしてください。この注釈をクラスターに残すと、演算子がフェイルオーバーなどの自己修復オペレーションを発行できなくなります。
