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