Failure Modes
=============

.. raw:: html

   <!-- SPDX-License-Identifier: CC-BY-4.0 -->

..  Note::
   CloudNativePGの以前のバージョンでは、このページには特定の障害シナリオが含まれていました。これらは主に標準のKubernetesの動作に従っているため、コンテンツを合理化して、基になるKubernetesスタックに属し、CloudNativePGに固有ではない情報の重複を回避しました。 CloudNativePGは、自己修復と高可用性のための標準のKubernetes原則に準拠しています。ストレージクラス、PVC、ノード、ポッドなどのコアKubernetes概念に精通していることを前提としています。 CloudNativePG固有の詳細については、スタートアップ、ライブネス、および準備状況プローブをカバーする :ref:`Postgres Instance Manager <Postgres Instance Manager>` および以下の :ref:`自己修復 <自己修復>` セクションを参照してください。

..  Note Important]::
   本番でCloudNativePGを実行している場合、 `professional support <https://cloudnative-pg.io/support/>`_ をシークすることを強くお勧めします。

自己修復
--------

一次障害
^^^^^^^^

プライマリポッドに障害が発生した場合

- オペレーターは、レプリケーションラグが最も低い最新のスタンバイをプロモートします。

- ``-rw`` サービスが更新されて、新しいプライマリをポイントします。

- 障害が発生したPodは、\ ``-r`` および\ ``-rw``
  サービスから削除されます。

- スタンバイポッドは、新しいプライマリから複製を開始します。

- 前者のプライマリは\ ``pg_rewind``
  を使用して、PVCが利用可能な場合を再同期します。それ以外の場合、新しいプライマリのバックアップから新しいスタンバイが作成されます。

スタンバイ障害
^^^^^^^^^^^^^^

スタンバイポッドに障害が発生した場合

- ``-r`` および\ ``-ro`` サービスから削除されます。

- ポッドは、PVCがある場合はそれを使用して再起動されます。それ以外の場合、新しいポッドは、現在のプライマリのバックアップから作成されます。

- 準備が整うと、Podは\ ``-r`` および\ ``-ro`` サービスに再追加されます。

手動介入
--------

自動復旧の対象とならない障害シナリオの場合、手動介入が必要になる場合があります。

..  Note Important]::
   `professional support <https://cloudnative-pg.io/support/>`_ なしで手動操作を実行しないでください。

リコンシリエーションの無効化
^^^^^^^^^^^^^^^^^^^^^^^^^^^^

``cnpg.io/reconciliationLoop``
アノテーションを使用すると、CloudNativePGリソースの調整ループを一時的に無効にすることができます。
``"disabled"``
に設定されている場合、オペレーターはアノテーション付きリソースの更新の処理を停止し、自動変更または自己修復アクションを防ぎます。

この注釈は **細心の注意を払って** 、緊急操作中にのみ使用してください。

..  Warning::
   このアノテーションは、問題が解決されたらすぐに削除する必要があります。そのままにすると、オペレーターはアノテーション付きリソースを管理できません。クラスターでは、これには自己修復アクションとフェイルオーバーが含まれます。次のリソースは、このアノテーションをサポートしています。

- **クラスター**
  PostgreSQLクラスターのリコンシリエーションを無効にします

- **Backup** バックアップ操作のリコンシリエーションを無効にします

使用例

.. code:: yaml

   metadata:
     name: cluster-example-no-reconcile
     annotations:
       cnpg.io/reconciliationLoop: "disabled"
   spec:
     # ...