Failure Modes ============= .. Note:: KubernetesのEDB Postgresの以前のバージョンでは、このページには特定の障害シナリオが含まれていました。これらは主に標準のKubernetesの動作に従っているため、コンテンツを合理化して、基になるKubernetesスタックに属し、KubernetesのEDB Postgresに固有ではない情報の重複を回避しました。 Kubernetes用EDB Postgresは、自己修復と高可用性のための標準のKubernetes原則に準拠しています。ストレージクラス、PVC、ノード、ポッドなどのコアKubernetes概念に精通していることを前提としています。 Kubernetes固有の詳細のためのEDB Postgresについては、startup、liveness、readnessプローブをカバーする :ref:`Postgres instance manager ` および以下の :ref:`自己修復のための自動フェイルオーバー <自己修復のための自動フェイルオーバー>` セクションを参照してください。 .. Important:: 実稼働環境でKubernetesのEDB Postgresを実行している場合、 `professional support `_ をシークすることを強くお勧めします。 自己修復 -------- 一次障害 ^^^^^^^^ プライマリポッドに障害が発生した場合 - オペレーターは、レプリケーションラグが最も低い最新のスタンバイをプロモートします。 - ``-rw`` サービスが更新されて、新しいプライマリをポイントします。 - 障害が発生したPodは、\ ``-r`` および\ ``-rw`` サービスから削除されます。 - スタンバイポッドは、新しいプライマリから複製を開始します。 - 前者のプライマリは\ ``pg_rewind`` を使用して、PVCが利用可能な場合を再同期します。それ以外の場合、新しいプライマリのバックアップから新しいスタンバイが作成されます。 スタンバイ障害 ^^^^^^^^^^^^^^ スタンバイポッドに障害が発生した場合 - ``-r`` および\ ``-ro`` サービスから削除されます。 - ポッドは、PVCがある場合はそれを使用して再起動されます。それ以外の場合、新しいポッドは、現在のプライマリのバックアップから作成されます。 - 準備が整うと、Podは\ ``-r`` および\ ``-ro`` サービスに再追加されます。 手動介入 -------- 自動復旧の対象とならない障害シナリオの場合、手動介入が必要になる場合があります。 .. Important:: `professional support `_ なしで手動操作を実行しないでください。 リコンシリエーションの無効化 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ PostgreSQLクラスターのリコンシリエーションループを一時的に無効にするには、 ``k8s.enterprisedb.io/reconciliationLoop`` アノテーションを使用します。 .. code:: yaml metadata: name: cluster-example-no-reconcile annotations: k8s.enterprisedb.io/reconciliationLoop: "disabled" spec: # ... この注釈は **細心の注意を払って** 、緊急操作中にのみ使用してください。 .. Warning:: このアノテーションは、問題が解決されたらすぐに削除する必要があります。そのままにすると、オペレーターはフェイルオーバーを含む自己修復アクションを実行できません。