Troubleshooting

このページでは、Kubernetesクラスター展開でCloudNativePGをトラブルシューティングする方法に関する基本的な情報を見つけることができます。

Tip

Kubernetes管理者は、 kubectl ページをブックマークする必要があります。

始める前に

Kubernetes環境

トラブルシューティングアクティビティに違いをもたらすのは、基になるKubernetesシステムに関する明確な情報を提供することです。

次のことを確認してください

  • 使用しているKubernetesディストリビューションとバージョン

  • PostgreSQLが実行されているノードの仕様

  • 運用に入る前に実行したストレージクラスとベンチマークを含む、実際の その他のS3互換オブジェクトストレージプロバイダー について可能な限り。

  • クラスターで使用している関連するKubernetesアプリケーションつまりPrometheus、Grafana、Istio、Certmanagerなど。

  • 継続的なバックアップの状況、特にそれが配置され、正常に動作している場合。そうでない場合、必ず 緊急バックアップ を取ってください

潜在的な破壊的な操作を実行する前に

便利なユーティリティ

トラブルシューティングの為、必須のkubectl ユーティリティに加えて、次のプラグイン/ユーティリティをシステムで使用できることをお勧めします。

  • kubectl の場合 postgresql.cnpg.io/v1

  • jq 、軽量で柔軟なコマンドラインJSONプロセッサー

  • grep 、1つ以上の入力ファイルで、指定されたパターンとの一致を含む行を検索します。これは、ほとんどの*nixディストリビューションで既に利用可能です。 Windows OSを使用している場合は、 grep の代替として findstr を使用するか、 wsl を直接使用できます。

そして、好みの*nixディストリビューションをインストールし、上記のツールを使用します。

最初の一歩

クラスターまたはインストールの概要をすばやく取得するために、kubectl プラグインは使用する主なツールです。

  1. status subcommand は、クラスターの概要を提供します

  2. report subcommand は、クラスターとオペレーター展開のマニフェストを提供します。 --logs オプションを使用してログを含めることもできます。プラグインを介して生成されたレポートには、完全なクラスターマニフェストが含まれます。

プラグインは、パッケージを介してエアギャップシステムにインストールできます。完全な手順については、 plugin document を参照してください。

バックアップはありますか？

プラグインでクラスターマニフェストを取得した後、バックアップがセットアップされ動作しているかどうかを確認する必要があります。

トラブルシューティング操作を続行する前に、バックアップに関する結果によっては、緊急バックアップを実行することをお勧めします。手順については、次のセクションを参照してください。

定期的なバックアップを保持せずに運用データベースを操作することは、 非常にリスク です。

緊急バックアップ

一部の緊急の状況では、メインのapp データベースの緊急論理バックアップを作成する必要がある場合があります。

注釈

以下にある指示は、緊急の場合、および一時的なバックアップファイルは、組織で有効なデータ保護ポリシーの下で保存される場合にのみ実行する必要があります。ダンプファイルは実際に`kubectl` コマンドを実行するクライアントマシンに保存されているため、すべての保護が設定されており、バックアップファイルを保存するための十分な領域があることを確認してください。

次の例は、cluster-example-1 ポッドからcluster-example Postgresクラスターのapp データベースの論理バックアップを取得する方法を示しています。

kubectl exec cluster-example-1 -c postgres \
  -- pg_dump -Fc -d app > app.dump

注釈

環境で使用したオブジェクトの名前を提供することにより、上記のコマンドをクラスターのバックアップに簡単に適合させることができます。

上記のコマンドは、カスタム形式でpg_dump コマンドを発行します。これは、 logical backups in PostgreSQL を取得する最も汎用性の高い方法です。

次の手順は、データベースを復元することです。初期化されたばかりの新しいPostgreSQLクラスターで操作していることを前提としていますので、 app データベースは空です。

次の例は、プライマリ new-cluster-example-1 ポッドに接続することにより、new-cluster-example Postgresクラスターのapp データベースに上記の論理バックアップを復元する方法を示しています。

kubectl exec -i new-cluster-example-1 -c postgres \
  -- pg_restore --no-owner --role=app -d app --verbose < app.dump

注釈

このセクションの例では、推奨に従って、ダンプとリストアの他のグローバルオブジェクトデータベースとロールがないことを前提としています。複数のロールがある場合は、 pg_dumpall -g を使用してバックアップをとり、新しいクラスターに手動で復元していることを確認します。複数のデータベースがある場合、一度に1つのデータベースごとに上記の操作を繰り返し、適切な所有権を割り当てていることを確認する必要があります。 PostgreSQLに慣れていない場合は、専門のサポート会社の指導の下でこれらの重要な操作を実行することをお勧めします。

上記の手順は、将来のある段階でcnpg プラグインに統合される可能性があります。

ログ

CloudNativePGによって作成および管理されるすべてのリソースは、 JSON形式のPostgreSQLエラーメッセージの標準出力ログ を使用して、Kubernetes規約に従って標準出力に記録されます。

ログは通常インフラレベルで処理され、CloudNativePGからのログが含まれますが、トラブルシューティング中にコマンドラインインターフェイスからログに直接アクセスすることが重要です。これには、3つの主なオプションがあります。

  • kubectl logs コマンドを使用して特定のリソースからログを取得し、読みやすいようにjq を適用します。

  • CloudNativePG固有のロギングには kubectl cnpg logs を使用します。

  • stern のような専用のオープンソースツールを活用し、複数のリソースたとえば、 cnpg.io/clusterName ラベルを選択してPostgreSQLクラスター内のすべてのポッドからログを集計し、ログエントリをフィルタリング、出力形式をカスタマイズできます。

注釈

以下のセクションでは、CloudNativePGのトラブルシューティングを行うときにさまざまなリソースのログを取得する方法の例を提供します。

オペレーター情報

デフォルトでは、CloudNativePGオペレーターはKubernetesのcnpg-system 名前空間にDeployment としてインストールされます デプロイメントの詳細 を参照してください

詳細についてはこちらをご覧ください。

次のコマンドを実行して、オペレーターポッドのリストを取得できます。

kubectl get pods -n cnpg-system

注釈

通常、オペレーターが実行されているポッドが1つあり、 cnpg-controller-manager- で始まる名前で識別されます。高可用性用にオペレーターを設定している場合、より多くのエントリがあるはずです。これらのポッドは、 cnpg-controller-manager という名前の展開によって管理されます。

次の方法を使用して、ポッド <POD> で実行されているオペレーターに関する関連情報を収集します。

kubectl describe pod -n cnpg-system <POD>

次に、次のコマンドを実行して同じポッドからログを取得します。

kubectl logs -n cnpg-system <POD>

オペレーターに関する詳細情報を収集する

次のコマンドを実行して、CloudNativePGオペレーター展開のすべてのポッドからログを取得しますマルチオペレーター展開がある場合。

kubectl logs -n cnpg-system \
  deployment/cnpg-controller-manager --all-containers=true

Tip

-f フラグを上記のコマンドに追加して、リアルタイムでログを追跡できます。

次のコマンドを実行して、ログをJSONファイルに保存します。

kubectl logs -n cnpg-system \
  deployment/cnpg-controller-manager --all-containers=true | \
  jq -r . > cnpg_logs.json

kubectl-cnpg プラグインを使用してCloudNativePGオペレーターバージョンを取得します。

kubectl-cnpg status <CLUSTER>

出力

Cluster in healthy state
Name:               cluster-example
Namespace:          default
System ID:          7044925089871458324
PostgreSQL Image:   ghcr.io/cloudnative-pg/postgresql:18.1-system-trixie
Primary instance:   cluster-example-1
Instances:          3
Ready instances:    3
Current Write LSN:  0/5000000 (Timeline: 1 - WAL File: 000000010000000000000004)

Continuous Backup status
Not configured

Streaming Replication status
Name               Sent LSN   Write LSN  Flush LSN  Replay LSN  Write Lag       Flush Lag       Replay Lag      State      Sync State  Sync Priority
- ---               --------   ---------  ---------  ----------  ---------       ---------       ----------      -----      ----------  -------------
cluster-example-2  0/5000000  0/5000000  0/5000000  0/5000000   00:00:00        00:00:00        00:00:00        streaming  async       0
cluster-example-3  0/5000000  0/5000000  0/5000000  0/5000000   00:00:00.10033  00:00:00.10033  00:00:00.10033  streaming  async       0

Instances status
Name               Database Size  Current LSN  Replication role  Status  QoS         Manager Version
- ---               -------------  -----------  ----------------  ------  ---         ---------------
cluster-example-1  33 MB          0/5000000    Primary           OK      BestEffort  1.12.0
cluster-example-2  33 MB          0/5000000    Standby (async)   OK      BestEffort  1.12.0
cluster-example-3  33 MB          0/5000060    Standby (async)   OK      BestEffort  1.12.0

クラスター情報

NAMESPACE 名前空間の<CLUSTER> クラスターのステータスは、次の方法で確認できます。

kubectl get cluster -n <NAMESPACE> <CLUSTER>

出力

NAME        AGE        INSTANCES   READY   STATUS                     PRIMARY
<CLUSTER>   10d4h3m    3           3       Cluster in healthy state   <CLUSTER>-1

上記の例では、すべてが 準備 状態で、<CLUSTER>-1 がプライマリである3つのインスタンスの正常なPostgreSQLクラスターをレポートします。

異常な状態の場合、 Cluster リソースのマニフェストを取得することにより、詳細を検出できます。

kubectl get cluster -o yaml -n <NAMESPACE> <CLUSTER>

収集するもう1つの重要なコマンドは、 cnpg プラグインが提供するstatus コマンドです。

kubectl cnpg status -n <NAMESPACE> <CLUSTER>

Tip

--verbose オプションを追加することにより、詳細情報を印刷できます。

PostgreSQLコンテナイメージバージョンを取得します。

kubectl describe cluster <CLUSTER_NAME> -n <NAMESPACE> | grep "Image Name"

出力

Image Name:    ghcr.io/cloudnative-pg/postgresql:18.1-system-trixie

注釈

また、 kubectl-cnpg status -n <NAMESPACE> <CLUSTER_NAME> を使用して同じ情報を取得できます。

ポッド情報

次の方法を使用して、特定のPostgreSQLクラスターに属するインスタンスのリストを取得できます。

kubectl get pod -l cnpg.io/cluster=<CLUSTER> -L role -n <NAMESPACE>

出力

NAME          READY   STATUS    RESTARTS   AGE       ROLE
<CLUSTER>-1   1/1     Running   0          10d4h5m   primary
<CLUSTER>-2   1/1     Running   0          10d4h4m   replica
<CLUSTER>-3   1/1     Running   0          10d4h4m   replica

次を実行して、ポッドに障害が発生しているかどうか、およびどのように障害が発生しているかを確認できます。

kubectl get pod -n <NAMESPACE> -o yaml <CLUSTER>-<N>

次の使用で、特定のPostgreSQLインスタンスのすべてのログを取得できます。

kubectl logs -n <NAMESPACE> <CLUSTER>-<N>

検索をPostgreSQLプロセスのみに制限したい場合は、次のコマンドを実行できます。

kubectl logs -n <NAMESPACE> <CLUSTER>-<N> | \
  jq select(.logger=="postgres") | .record.message

次の例では、タイムスタンプも追加します。

kubectl logs -n <NAMESPACE> <CLUSTER>-<N> | \
  jq -r select(.logger=="postgres") | [.ts, .record.message] | @csv

タイムスタンプがUnixエポック時間で表示されている場合、使いやすい形式に変換できます。

kubectl logs -n <NAMESPACE> <CLUSTER>-<N> | \
  jq -r select(.logger=="postgres") | [(.ts|strflocaltime("%Y-%m-%dT%H:%M:%S %Z")), .record.message] | @csv

PostgreSQLポッドに関する追加情報を収集およびフィルタリングする

クラッシュした特定のポッドからログを確認します。

kubectl logs -n <NAMESPACE> --previous <CLUSTER>-<N>

特定のPostgreSQLポッドからFATALエラーを取得します。

kubectl logs -n <NAMESPACE> <CLUSTER>-<N> | \
  jq -r .record | select(.error_severity == "FATAL")

出力

{
  "log_time": "2021-11-08 14:07:44.520 UTC",
  "user_name": "streaming_replica",
  "process_id": "68",
  "connection_from": "10.244.0.10:60616",
  "session_id": "61892f30.44",
  "session_line_num": "1",
  "command_tag": "startup",
  "session_start_time": "2021-11-08 14:07:44 UTC",
  "virtual_transaction_id": "3/75",
  "transaction_id": "0",
  "error_severity": "FATAL",
  "sql_state_code": "28000",
  "message": "role \"streaming_replica\" does not exist",
  "backend_type": "walsender"
}

特定のポッドのログにあるPostgreSQL DBエラーメッセージをフィルタリングします。

kubectl logs -n <NAMESPACE> <CLUSTER>-<N> | jq -r .err | select(. != null)

出力

dial unix /controller/run/.s.PGSQL.5432: connect: no such file or directory

err ワードと一致するメッセージを特定のポッドから取得します。

kubectl logs -n <NAMESPACE> <CLUSTER>-<N> | jq -r .msg | grep "err"

出力

2021-11-08 14:07:39.610 UTC [15] LOG:  ending log output to stderr

特定のポッドからPostgreSQLプロセスからすべてのログを取得します。

kubectl logs -n <NAMESPACE> <CLUSTER>-<N> | \
  jq -r . | select(.logger == "postgres") | select(.msg != "record") | .msg

出力

2021-11-08 14:07:52.591 UTC [16] LOG:  redirecting log output to logging collector process
2021-11-08 14:07:52.591 UTC [16] HINT:  Future log output will appear in directory "/controller/log".
2021-11-08 14:07:52.591 UTC [16] LOG:  ending log output to stderr
2021-11-08 14:07:52.591 UTC [16] HINT:  Future log output will go to log destination "csvlog".

値を含むフィールドでフィルタリングされたPodログを取得し、実行している| で区切って結合します。

kubectl logs -n <NAMESPACE> <CLUSTER>-<N> | \
  jq -r [.level, .ts, .logger, .msg] | join(" | ")

出力

info | 1636380469.5728037 | wal-archive | Backup not configured, skip WAL archiving
info | 1636383566.0664876 | postgres | record

バックアップ情報

次の使用で、名前付けクラスターに対して作成されたバックアップをリストできます。

kubectl get backup -l cnpg.io/cluster=<CLUSTER>

ストレージ情報

次のように、クラスターが使用するStorageClassをダブルチェックして、調査またはトラブルシューティング中により多くのコンテキストを理解すると役立つ場合があります。

STORAGECLASS=$(kubectl get pvc <POD> -o jsonpath={.spec.storageClassName})
kubectl get storageclasses $STORAGECLASS -o yaml

多くの場合、クラスターはデフォルトのStorageClassを使用して作成されるため、ここではクラスターポッドの1つからStorageClassを取得します。

ノード情報

Kubernetesノードは、最終的にPostgreSQLポッドが実行される場所です。それらについてできるだけ多くを知ることが戦略的に重要です。

次の使用で、Kubernetesクラスター内のノードのリストを取得できます。

##  look at the worker nodes and their status

kubectl get nodes -o wide

さらに、特定のクラスターのポッドが実行されているノードのリストを収集できます。

kubectl get pod -l cnpg.io/cluster=<CLUSTER> \
  -L role -n <NAMESPACE> -o wide

後者は、ポッドがどこに分散されているかを理解するために重要です。 affinity/anti-affinity rules and/or tolerations を使用している場合に非常に役立ちます。

条件

多くのネイティブkubernetesオブジェクト like here と同様に、クラスターはstatus.conditions も公開します。これにより、クラスター全体の状態に依存するのではなく、特定のイベントが発生するを「待機」できます。現在利用可能な条件は次のとおりです。

  • LastBackupSucceeded

  • 継続的アーカイブ

  • 準備完了

LastBackupSucceeded は、最新のバックアップのステータスを報告しています。 True に設定されている場合、最後のバックアップは正しく取得されており、それ以外の場合はFalse に設定されます。

ContinuousArchiving は、WALアーカイブのステータスを報告しています。 True に設定されている場合、最後のWALアーカイブプロセスは正常に終了しており、それ以外の場合はFalse に設定されます。

クラスターにユーザーが指定した数のインスタンスがあり、プライマリインスタンスの準備ができている場合、 Ready はTrue です。この条件は、クラスターが作成されるのを待機するスクリプトで使用できます。

特定の条件を待機する方法

  • バックアップ

$ kubectl wait --for=condition=LastBackupSucceeded cluster/<CLUSTER-NAME> -n <NAMESPACE>

  • 継続的アーカイブ

$ kubectl wait --for=condition=ContinuousArchiving cluster/<CLUSTER-NAME> -n <NAMESPACE>

  • Ready クラスターの準備ができているかどうか。

$ kubectl wait --for=condition=Ready cluster/<CLUSTER-NAME> -n <NAMESPACE>

以下は、失敗条件を含むcluster.status のスニペットです。

$ kubectl get cluster/<cluster-name> -o yaml
.
.
.
  status:
    conditions:
    - message: unexpected failure invoking barman-cloud-wal-archive: exit status
        2
      reason: ContinuousArchivingFailing
      status: "False"
      type: ContinuousArchiving

    - message: exit status 2
      reason: LastBackupFailed
      status: "False"
      type: LastBackupSucceeded

    - message: Cluster Is Not Ready
      reason: ClusterIsNotReady
      status: "False"
      type: Ready

ネットワーキング

CloudNativePGには、基本的なネットワーキングと接続が必要です。詳細については、 Networking セクションをご覧ください。

既存の環境にCloudNativePGをインストールする場合、ネットワークポリシー、またはクラスター専用に作成されたその他のネットワーク構成が存在する可能性があります。これは、オペレーターとクラスターポッド間および/またはポッド間の必要な接続に影響を与える可能性があります。

次のコマンドを使用して、既存のネットワークポリシーを検索できます。

kubectl get networkpolicies

Kubernetesネットワーク管理者によって設定された複数のネットワークポリシーが存在する場合があります。

$ kubectl get networkpolicies
NAME                   POD-SELECTOR                      AGE
allow-prometheus       cnpg.io/cluster=cluster-example   47m
default-deny-ingress   <none>                            57m

PostgreSQLコアダンプ

まれに、PostgreSQLはクラッシュし、PGDATA フォルダーにコアダンプを生成する場合があります。それが発生した場合、通常、それはPostgreSQLのバグであり、ほとんどの場合、既に解決されています。これが、常にPostgreSQLの最新のマイナーバージョンを実行することが重要である理由です。

CloudNativePGでは、 cnpg.io/coredumpFilter アノテーションを介してコアダンプに含めるものを制御できます。

注釈

Labels and Annotations を参照してください。

CloudNativePGが提供する標準のアノテーションの詳細については、 をご覧ください。

デフォルトでは、これがほとんどの場合最も安全なアプローチであるため、ダンプから共有メモリセグメントを除外するために、 cnpg.io/coredumpFilter は0x31 に設定されます。

注釈

Core dump filtering settings を参照してください。コアダンプフィルタを制御するビットマスクを設定する方法の詳細については、

注釈

この設定はポッドの起動中にのみ有効になり、アノテーションを変更してもインスタンスの自動ロールアウトはトリガーされないことに注意してください。

あなたはコアダンプの検査に個人的に関わっていないかもしれませんが、 Postgresの専門家がそれらを調べることができるようにそれらの提供を求められる場合があります。まず、次のコマンドを使用して、PGDATA ディレクトリにコアダンプがあることを確認します。Postgresインスタンスが実行されている正しいポッドに対して実行してください。

kubectl exec -ti POD -c postgres \
  -- find /var/lib/postgresql/data/pgdata -name core.*

通常、これは空のセットを返すはずです。例、コアダンプファイルがあるとします。

/var/lib/postgresql/data/pgdata/core.14177

ディスク上の領域が十分であることを確認したら、次のようにkubectl cp を介してマシンでコアダンプを収集できます。

kubectl cp POD:/var/lib/postgresql/data/pgdata/core.14177 core.14177

これで、ファイルができました。コアダンプを削除して、サーバー上の領域を解放してください。

プロファイリングデータの視覚化と分析

CloudNativePGは pprof と統合して、2つのレベルでプロファイリングデータを収集および分析します。

  • オペレーターレベル – --pprof-server=true オプションをオペレーター展開に追加することにより有効にします Operator configuration を参照してください。

  • Postgresクラスターレベル – alpha.cnpg.io/enableInstancePprof アノテーションをCluster リソース以下に説明を追加することにより有効にします。

alpha.cnpg.io/enableInstancePprof アノテーションが"true" に設定されている場合、各インスタンスポッドは、インスタンスマネージャーが提供するGo pprof HTTPサーバーを公開します。

  • サーバーはポッド内の0.0.0.0:6060 でリッスンします。

  • pprof 6060/TCP という名前のコンテナポートがポッド仕様に自動的に追加されます。

アノテーションを削除するか、"false" に設定することにより、いつでもpprofを無効にできます。オペレーターは変更を自動的にロールアウトして、pprofポートとフラグを削除します。

注釈

pprofサーバーは、ポート`6060` でプレーンHTTPのみを提供します。

例

次のアノテーションを追加して、クラスターでpprofを有効にします。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example
  annotations:
    alpha.cnpg.io/enableInstancePprof: "true"
spec:
  instances: 3
  # ...

このアノテーションを変更すると、インスタンスポッド仕様が更新されポート6060 および対応するフラグが追加され、ローリング更新がトリガーされます。

警告

次の例では、ローカルテストのみに`kubectl port-forward` を使用します。これは、運用環境で機能を公開するための意図された方法ではありません**。 pprofを機密デバッグインターフェイスとして扱い、決して公開しないでください。リモートでアクセスする必要がある場合は、適切なネットワークポリシーとアクセス制御で保護してください。

ポート転送を使用してpprofエンドポイントにアクセスします。

kubectl port-forward -n <namespace> pod/<instance-pod> 6060
curl -sS http://localhost:6060/debug/pprof/
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30

http://localhost:6060/debug/pprof/ ブラウザーを使用してpprofにアクセスすることもできます。

障害対応

最初に、クラスターにalpha.cnpg.io/enableInstancePprof: "true" アノテーションセットがあることを確認します。

次に、instance managerコマンドに--pprof-server フラグが含まれ、ポート6060/TCP が公開されていることを確認します。これは、次を実行して行うことができます。

kubectl -n <namespace> describe pod <instance-pod>

次に、出力の Command および Ports セクションを確認します。

最後に、ポート転送を使用していない場合は、ネットワークポリシーがポート6060/TCP へのアクセスを許可していることを確認します。

いくつかの既知の問題

ストレージがいっぱいです

ストレージがいっぱいの場合、PostgreSQLポッドは新しいデータを書き込むことができません。または、WALセグメントを含むディスクがいっぱいである場合、PostgreSQLはシャットダウンします。

ディスクがいっぱいであることに関するメッセージがログにある場合は、影響を受けるPVCのサイズを増やす必要があります。これは、PVCを編集し、spec.resources.requests.storage フィールドを変更することにより行うことができます。その後、新しいサイズでクラスターリソースを更新して、同じ変更をすべてのポッドに適用する必要があります。ドキュメントの ボリュームの拡張 を参照してください。

WALセグメントの領域が使い果たされると、ポッドはクラッシュループし、クラスターステータスはNot enough disk space と報告されます。 PVC、次にクラスターリソースのサイズを増やすと、問題が解決されます。 ディスクフル障害 も参照してください。

ポッドがPending 状態でスタックしている

クラスターのインスタンスがPending フェーズでスタックしている場合、ポッドのEvents セクションを確認して、この背後にある理由を理解する必要があります。

kubectl describe pod -n <NAMESPACE> <POD>

この考えられる原因の一部は次のとおりです。

  • nodeSelector と一致するノードはありません

  • Tolerationがノードのテイントと一致するように正しく構成されていません

  • 利用可能なノードがまったくありません。これは、cluster-autoscaler がいくつかの制限に到達したこと、または一時的な問題が発生したことに関連している可能性があります。

この場合、名前空間内のイベントをチェックすることも役立つ場合があります。

kubectl get events -n <NAMESPACE>

##  list events in chronological order

kubectl get events -n <NAMESPACE> --sort-by=.metadata.creationTimestamp

バックアップが構成されていない場合、レプリカが同期していない

場合によっては、メンテナンスのため、レプリカが少しの間オフになる場合がありますKubernetesノードがドレインされたときを考えてください。クラスターにバックアップが構成されていない場合、レプリカがバックアップすると、プライマリにはもう存在しないWALファイル :ref:``postgresql` セクション <postgresql セクション>` で述べているように、WAL管理ポリシーに従って既にリサイクルされており、フォールアウトする場合があります同期のこと。

同様に、pg_rewind が以前のプライマリに存在しないWALファイルを必要とする場合、 pg_rewind: error: could not open file をレポートします。

これらの場合、ポッドの準備ができなくなるため、PVCを削除し、オペレーターにレプリカを再構築してもらう必要があります。

動的にプロビジョニングされた永続ボリュームに依存し、PV自分自身を削除することに自信がある場合は、次の方法で削除できます。

PODNAME=<POD>
VOLNAME=$(kubectl get pv -o json | \
  jq -r .items[]|select(.spec.claimRef.name==\"$PODNAME\")|.metadata.name)

kubectl delete pod/$PODNAME pvc/$PODNAME pvc/$PODNAME-wal pv/$VOLNAME

クラスターがCreating new replica でスタックしている

クラスターは「新しいレプリカの作成」でスタックしていますが、ポッドログには関連する問題は表示されません。これは、次の問題 インストールされたネットワークポリシーにより、ネットワーキングが障害されます に関連していることがわかりました。ネットワークの問題は、次のようにステータス列に反映されます。

Instance Status Extraction Error: HTTP communication issue

インストールされたネットワークポリシーにより、ネットワーキングが障害されます

Networking で指摘されたように、ローカルネットワークポリシーは、必要な接続の一部を妨げる可能性があります。

接続が障害されていることを示す兆候は、オペレーターログに次のようなメッセージが存在することです。

"Cannot extract Pod status", […snipped…] "Get \"http://<pod IP>:8000/pg/status\": dial tcp <pod IP>:8000: i/o timeout"

ネットワークポリシーをリストし、接続を制限するポリシーを探す必要があります。

$ kubectl get networkpolicies
NAME                   POD-SELECTOR                      AGE
allow-prometheus       cnpg.io/cluster=cluster-example   47m
default-deny-ingress   <none>                            57m

たとえば、上記のリストでは、 default-deny-ingress が犯人である可能性が高いと思われます。それをドリルダウンできます。

$ kubectl get networkpolicies default-deny-ingress -o yaml
<…snipped…>
spec:
  podSelector: {}
  policyTypes:
  - Ingress

networking page には、オペレーターがクロスネームスペースをクラスターポッドに接続できるようにするNetworkPolicy を作成するようにカスタマイズできるネットワークポリシーファイルがあります。

データディレクトリのブートストラップ中のエラー

クラスターの初期化ジョブが「バスエラーコアダンプされた子プロセスが終了コード135で終了しました」でクラッシュした場合、クラスターhugepages設定を修正する必要がある可能性があります。

その理由は、v2で修正する必要があるcgroup v1のhugeページのサポートが不完全であるためです。詳細については、 PostgreSQL BUG #17757: Nothonoring huge_pages setting during initdb causes DB crash inKubernetes を確認してください。

hugeページが有効になっているかどうかを確認するには、Kubernetesノードでgrep HugePages /proc/meminfo を実行し、hugepageが存在するかどうか、そのサイズ、および空き数を確認します。

hugeページが存在する場合、すべてのPostgreSQLポッドで使用可能なhugepageメモリの量を構成する必要があります。

例

postgresql:
  parameters:
    shared_buffers: "128MB"

resources:
  requests:
    memory: "512Mi"
  limits:
    hugepages-2Mi: "512Mi"

クラスター内のすべてのポッドをスケジュールするには、十分なhugepagesメモリが必要であることに注意してください。上記の例では、ポッドごとに少なくとも512MiBを解放する必要があります。

ブートストラップジョブが実行中ステータスでハングする

Running ステータスにあるときにクラスターの初期化ジョブがハングし、メッセージ「APIサーバーが到達可能になるのを待機しているときにエラーが発生した場合」は、おそらくネットワークに問題があり、Kubernetes APIサーバーとの通信を妨げています。初期化ジョブほとんどのジョブと同様に、Kubernetes APIにアクセスする必要があります。ネットワークを確認してください。

もう1つの考えられる原因は、サイドカーインジェクションを構成している場合です。 Istioなどのサイドカーは、起動中にネットワークを一時的に利用できなくなる場合があります。サイドカーインジェクションを有効にしている場合は、インジェクションを無効にして再試行します。

レプリカは、フェールオーバー後の再接続に2分以上かかります

プライマリインスタンスに障害が発生すると、オペレーターは最も高度なスタンバイをプライマリロールに昇格させます。他のスタンバイインスタンスは、レプリケーションのために-rw サービスに再接続しようとします。ただし、この再接続プロセス中に、kube-proxy はルーティング情報をまだ更新していない場合があります。その結果、スタンバイインスタンスによって送信された最初のSYN パケットは、目的の宛先に到達しない場合があります。

ネットワークがパケットを拒否するのではなく、サイレントにドロップするように構成されている場合、スタンバイインスタンスは応答を受信せず、指数バックオフ期間の後に接続を再試行します。 Linuxシステムでは、 tcp_syn_retries カーネルパラメーターのデフォルト値は6です。これは、システムが断念するまでに約127秒間の接続の確立を試行することを意味します。この再試行期間が長くなると、再接続プロセスが大幅に遅延する可能性があります。詳細については、

tcp_syn_retries documentation を参照してください。

Operator configuration でSTANDBY_TCP_USER_TIMEOUT を設定することにより、この問題をワークアラウンドできます。これにより、最初のSYN パケットが指定されたタイムアウト内に確認されない場合、スタンバイインスタンスはTCP接続を閉じ、より迅速に接続を再試行できます。