よくある質問

このセクションでは、パトローニに関してよくある質問への回答を示します。各サブセクションでは、さまざまな種類の質問に焦点を当てようとしています。

これがあなたの質問のほとんどを明確にするのに役立つことを願っています。さらに懸念がある場合、または予期しない問題に直面している場合は、 チャット および チャット のヘルプを取得または問題を報告する方法を参照してください。

他のHAソリューションとの比較

repmgr のような他のソリューションは必要ないのに、PatroniはDCSノードの別のクラスターを必要とするのはなぜですか?

HAソリューションを実装するにはさまざまな方法があり、それぞれに長所と短所があります。

repmgr のようなソフトウェアは、ノード間で通信を実行して、アクションを実行する時期を決定します。

一方、Patroniは、DCSに保存されている状態に依存します。 DCSは、パトローニが何をすべきかを決定するための真実の情報源として機能します。

別のDCSクラスターを持つとアーキテクチャが肥大化する可能性がありますが、このアプローチでは、Postgresクラスターでスプリットブレインシナリオが発生する可能性が低くなります。

Postgres管理に関するPatroniと他のHAソリューションの違いは何ですか？

Patroniは、Postgresクラスターの高可用性を管理するだけでなく、Postgres自分自身も管理します。

Postgresノードがまだ存在しない場合、プライマリノードとスタンバイノードのブートストラップを処理し、ノードのPostgres構成も管理します。 Postgresノードが既に存在する場合、Patroniはクラスターの管理を引き継ぎます。

上記に加えて、Patroniには自己修復機能もあります。言い換えれば、プライマリノードに障害が発生すると、Patroniはレプリカにフェールオーバーするだけでなく、新しいプライマリのレプリカとして元のプライマリに再参加しようとします。同様に、レプリカに障害が発生すると、Patroniはそのレプリカに再参加しようとします。

これは、Patroniを/「HAソリューションのテンプレート」と呼ぶ方法です。単に物理的レプリケーションを管理するだけでなく、Postgres全体を管理します。

DCS

同じ etcd クラスターを使用して、2つ以上のPatroniクラスターからのデータを保存できますか?

はい、できます！

Patroniクラスターに関する情報は、DCSの namespace および scope Patroni設定の接頭辞が付いているパスの下に保存されます。

異なるPatroniクラスター間で競合する名前空間とスコープがない限り、同じDCSクラスターを使用して、複数のPatroniクラスターからの情報を保存できるはずです。

同じDCSクラスターを指すさまざまなPatroniクラスターで namespace と scope の同じ組み合わせを使用しようとすると、どうなりますか?

同じ namespace および scope を使用しようとする2番目のPatroniクラスターは、DCSで同じ組み合わせに関連する情報を見つけようとするため、Postgresを管理できません。ただし、互換性のないPostgresシステム識別子。システム識別子の不一致により、Patroniは2番目のクラスターが別のクラスターを参照し、ユーザーがPatroniの構成を誤っていると仮定して、2番目のクラスターの管理を中止します。

同じDCSクラスターを共有するさまざまなPatroniクラスターを扱う場合、必ず別の namespace / scope を使用してください。

DCSクラスターを失うとどうなりますか?

DCSは、基本的にPatroniクラスターのステータスと動的構成を保存するために使用されます。

彼らの最初の結果は、そのDCSに依存するすべてのPatroniクラスターが読み取り専用モードになるということです- DCSフェイルセーフモード が有効になっていない限り

DCSクラスターを失った場合はどうすればよいですか?

DCSクラスターを失った場合、考えられる結果は3つあります。

  1. DCSクラスターは完全に復旧しました。これには、Patroni側からのアクションは必要ありません。 DCSクラスターが復旧すると、Patroniも復旧できるはずです。

  2. DCSクラスターは適切な場所に再作成され、エンドポイントは同じままです。 Patroni側で変更は必要ありません。

  3. 新しいDCSクラスターがさまざまなエンドポイントで作成されます。各PatroniノードのPatroni構成のDCSエンドポイントを更新する必要があります。

2. または 3. シナリオに直面した場合、 Patroniは、クラスターの現在のステータスに基づいてステータス情報を再度作成し、 のPostgresデータディレクトリ内に保存されている patroni.dynamic.json という名前のバックアップファイルに基づいてDCSで動的構成を再作成します。 Patroniクラスターの各メンバー。

DCSクラスターのマジョリティを失うとどうなりますか?

DCSは応答しなくなり、Patroniは現在の読み取り/書き込みPostgresノードを降格します。

注PatroniはDCSの状態に依存して、クラスターでアクションを実行します。

DCSフェイルセーフモード を使用して、その状況を緩和できます。

patronicl

Patroniホストで patronicl を実行する必要がありますか?

いいえ、その必要はありません。

patronicl アプリケーションの patroni エージェントからまったく同じ構成ファイルを使用できるため、Patroniホストにアクセスできる場合、Patroniホストで patronicl を実行すると便利です。

ただし、 patronicl は基本的にクライアントであり、リモートマシンから実行できます。 PatroniメンバーのDCSとREST APIに到達できるように、十分な構成を提供するだけです。

Patroniメンバーの1人からの情報が 後援者リスト コマンドの出力から消えたのはなぜですか?

後援者リスト で表示される情報は、DCSの内容に基づいています。

メンバーに関する情報がDCSから消えた場合、そのノードでPatroniエージェントが実行されていないか、DCSと通信できません。

メンバーは情報を更新できないため、最終的にDCSからの情報の有効期限が切れ、その結果、メンバーは 後援者リスト の出力に表示されません。

後援者リスト コマンドの出力で、Patroniメンバーの1つに関する情報が最新でないのはなぜですか?

後援者リスト で表示される情報は、DCSの内容に基づいています。

デフォルトでは、その情報はPatroniによっておよそ loop_wait 秒ごとに更新されます。言い換えれば、すべてが正常に機能している場合でも、DCSに保存されている情報に最大 loop_wait 秒の/"migrate"が表示される場合があります。

ただし、それはルールではないことに注意してください。 Patroniによって実行される一部の操作では、DCS情報がすぐに更新されます。

構成

動的構成とローカル構成の違いは何ですか?

動的構成またはグローバル構成は、DCSに保存され、Patroniクラスターのすべてのメンバーに適用される構成です。これは、主に構成を保存する場所です。

ノードに固有の設定、またはグローバル構成を上書きする設定は、目的のPatroniメンバーにのみローカル構成として設定する必要があります。そのローカル構成は、構成ファイルまたは環境変数を介して指定できます。

パトローニ構成 の詳細を参照してください。

Patroniの構成の種類と優先順位は何ですか?

種類は次のとおりです。

  • 動的構成 すべてのメンバーに適用されます。

  • ローカル構成 ローカルメンバーに適用され、動的構成をオーバーライドします。

  • 環境構成 ローカルメンバーに適用され、動的構成とローカル構成の両方をオーバーライドします。

Note: 一部のPostgres GUCは、グローバル、つまり動的構成を介してのみ設定できます。それに加えて、Patroniがハードコーディングされた値を強制するGUCがあります。

パトローニ構成 の詳細を参照してください。

Patroni構成ファイルの作成に役立つ機能はありますか?

はい、あります。

patroni --generate-sample-config または patroni --generate-config コマンドを使用して、サンプルのPatroni構成または既存のPostgresインスタンスに基づいてPatroni構成を生成できます。

詳細については、 Patroni構成のサンプル および Patroni構成のサンプル を参照してください。

bootstrap.dcs 構成でパラメーターを変更しましたが、Patroniはクラスターメンバーに変更を適用していません。何が間違っているのでしょうか？

bootstrap.dcs で構成された値は、新しいクラスターをブートストラップする場合にのみ使用されます。これらの値は、ブートストラップ中にDCSに書き込まれます。

ブートストラップフェーズが完了すると、DCSを介してのみ動的構成を変更できます。

詳細については、次の質問を参照してください。

動的構成を変更するにはどうすればよいですか?

DCSの構成を変更する必要があります。これは、次のいずれかを通じて実現されます。

ローカル構成を変更するにはどうすればよいですか?

対応するPatroniメンバーの構成ファイルを変更し、 SIHGUP でPatroniエージェントに通知する必要があります。これは、次のいずれかのアプローチを使用して行うことができます。

  • POST 要求をREST API POST に送信します。または

  • patronicl reload を実行します。または

  • SIGHUP を使用してPatroniプロセスにローカルに通知します。

    • systemdを介してPatroniを起動した場合、次のコマンドを使用できます systemctl reload PATRONI_UNIT.service 、 PATRONI_UNIT はPatroniサービスの名前です。または

    • 他の方法でPatroniを起動した場合、 patroni プロセスを特定し、 kill -s HUP PID を実行する必要があります。 PID は、 patroni プロセスのプロセスIDです。

Note: Note: を介したリロードが機能しない場合があります。

  • 有効期限が切れたREST API証明書 -k の -k オプションを使用して、これを緩和できます。

  • 間違った資格情報たとえば、構成ファイルの restapi または ctl 資格情報を変更し、 Patroniと restapi に同じ構成ファイルを使用する場合。

環境構成を変更するにはどうすればよいですか?

環境構成は、起動中にPatroniによってのみ読み取られます。

それを念頭に置いて、環境構成を変更した場合は、対応するPatroniエージェントを再起動する必要があります。

クラスターでフェールオーバーが発生しないように注意してください。 patronicl 一時停止 をチェックすることに興味があるかもしれません。

リロードが必要なPostgres GUCを変更するとどうなりますか?

以前の質問で説明したように動的またはローカル構成を変更すると、PatroniはPostgres構成のリロードを担当します。

再起動が必要なPostgres GUCを変更するとどうなりますか?

Patroniは、影響を受けるメンバーを pending restart のフラグでマークします。

メンバーを再起動する時期と方法は、あなたが決定する必要があります。これは、次のいずれかの方法で実現できます。

Note: 一部のPostgres GUCでは、Postgresノードを再起動する順序の点で特別な管理が必要です。詳細については、 Note: を参照してください。

Patroni構成の etcd と etcd3 の違いは何ですか？

etcd は etcd のAPIバージョン2を使用し、 etcd3 は etcd のAPIバージョン3を使用します。

APIバージョン2で保存されている情報はAPIバージョン3では管理できないことに注意してください。その逆も可能です。

次の理由から、 etcd ではなく etcd3 を構成することをお勧めします。

  • APIバージョン2は、Etcd v3.4以降、デフォルトで無効になっています。

  • APIバージョン2は、Etcd v3.6で完全に削除されます。

Patroni構成で use_slots を有効にしていますが、クラスターメンバーがしばらくオフラインになると、そのメンバーが使用するレプリケーションスロットが上流ノードでドロップされます。その問題を回避するにはどうすればよいですか？

2つのオプションがあります。

  1. member_slots_ttl デフォルト値 30min 、Patroni 4.0.0 およびPostgreSQL 11以降から利用可能

  2. メンバーの永続的な物理レプリケーションスロットを構成できます。

Patroni 3.2.0 から、メンバースロットをPatroniが管理する永久スロットとして持つことが可能になりました。

Patroniは、すべてのノードに永続的な物理スロットを作成し、スロットを削除しないことを確認するだけでなく、メンバーが消費したLSNに従って、すべてのノードのスロットのLSNを進めます。

後で、対応するメンバーを削除することにした場合は、永続的なスロット構成を調整するのが your responsibility です。それ以外の場合、Patroniはスロットを永久に保持します。

Note: 3.2.0 より古いPatroniでは、メンバースロットを永続的な物理スロットとして構成できますが、それらは現在のリーダーでのみ管理されます。つまり、フェイルオーバー/スイッチオーバーの場合、これらのスロットは新しいリーダーで作成されますが、存在しないノードのすべてのWALセグメントがあることは保証されません。

Note: Patroni 3.2.0 を使用しても、小さな競合状態が発生する可能性があります。一番最初に、スロットがレプリカで作成されると、リーダーの同じスロットより前にある可能性があり、誰もスロットを消費していない場合、フェールオーバー後にいくつかのファイルが失われる可能性があります。それを念頭に置いて、継続的アーカイブを構成することをお勧めします。これにより、必要なWALを復元したり、PITRを実行したりできます。

loop_wait 、 retry_timeout 、 ttl の違いは何ですか？

Patroniは、HAサイクルと呼ばれるものを実行する場合があります。各HAサイクルで、クラスターで一連のチェックを実行してその正常性を判断し、ステータスによっては、スタンバイへのフェールオーバーなどのアクションを実行する場合があります。

loop_wait は、HAチェックの新しいサイクルを実行する前にPatroniがスリープする時間を秒単位で決定します。

retry_timeout は、DCSおよびPostgresでの再試行操作のタイムアウトを設定します。例えば DCSが retry_timeout 秒を超えて応答しない場合、Patroniはセキュリティアクションとしてプライマリノードを降格する場合があります。

ttl は、DCSの leader ロックのリース時間を設定します。クラスターの現在のリーダーがHAサイクル中に ttl より長くリースを更新できない場合、リースは有効期限が切れ、クラスター内の leader race がトリガーされます。

Note: これらの設定を変更するときは、Patroniがドキュメントの Note: セクションで説明されているルールと最小値を適用することに注意してください。

Postgres管理

Postgres構成でPostgres GUCを直接変更できますか?

できますが、それは避けたほうがいいです。

Postgresの構成はPatroniによって管理され、構成ファイルを編集しようとすると、最終的に上書きされる可能性があるため、Patroniによって挫折される場合があります。

Patroniによって実行される管理を克服するために使用できるオプションがいくつかあります。

  • $PGDATA/postgresql.base.conf を介してPostgres GUCを変更します。または

  • postgresql.base.conf の代わりに使用される postgresql.custom_conf を定義して、外部で管理できるようにします。または

  • ALTER SYSTEM / ALTER DATABASE / ALTER USER を使用してGUCを変更します。

これに関する詳細については、セクション 重要なルール を参照してください。

いずれの場合も、Patroniを介してすべてのPostgres構成を管理することをお勧めします。これにより、管理が一元化され、必要に応じてPatroniのデバッグが簡単になります。

Postgresノードを直接再起動できますか?

いいえ、 not Postgresを直接管理してみる必要があります。

PatroniなしでPostgresサーバーをバウンスしようとすると、クラスターがフェールオーバーに直面する可能性があります。

Postgresサーバーを管理する必要がある場合は、Patroniが公開した方法を介してそれを行ってください。

Patroniは、既存のPostgresクラスターの管理を引き継ぐことができますか?

はい、できます！

詳しい手順については、 スタンドアロンをPatroniクラスターに変換する を参照してください。

PatroniはPostgresをどのように管理していますか？

Patroniは、 pg_ctl や postgres などのPostgresバイナリを実行することにより、Postgresのアップとダウンを処理します。

それを念頭に置いて、systemdユニットなどのPostgresクラスターを管理できる他のソースを MUST 無効にします。 postgresql.service 。 Patroniのみがクラスター内のPostgresインスタンスを起動、停止、および昇格できる必要があります。そうしないと、スプリットブレインシナリオが発生する可能性があります。例えば プライマリとして実行されているノードに障害が発生し、ユニット postgresql.service が有効になっている場合、Postgresがバックアップされ、スプリットブレインが発生する場合があります。

概念と要件

Patroniの一部を構成するアプリケーションは何ですか?

Patroniは基本的にいくつかのアプリケーションを同梱しています。

  • patroni これはPatroniエージェントであり、Postgresノードの管理を担当します。

  • patronictl これは、Patroniクラスターと対話するために使用されるコマンドラインユーティリティです。スイッチオーバー、再起動、構成の変更などを実行します。詳細については、 patronictl をご覧ください。

Patroniの standby cluster とは何ですか?

これは、プライマリPostgresノードが実行されていないクラスターです。つまり、クラスター内に読み取り/書き込みメンバーがありません。

これらの種類のクラスターは、別のクラスターからデータをレプリケートするために存在し、通常はデータセンター間でデータをレプリケートする場合に役立ちます。

クラスター内には、リモートのPostgresノードから変更をレプリケートするスタンバイとなるリーダーが存在します。次に、このようなリーダーメンバーからのカスケードレプリケーションで構成されたスタンバイのセットが存在します。

Note: スタンバイクラスターは、複製元のソースクラスターについて何も知りません。WALストリーミングの代わりに restore_command を使用することもでき、完全に独立したDCSクラスターを使用する場合があります。

詳細については、 スタンバイクラスター を参照してください。

Patroniの leader とは何ですか?

Patroniの leader は、クラスターのコーディネーターのようなものです。

通常のPatroniクラスターでは、 leader が読み取り/書き込みノードになります。

スタンバイPatroniクラスターでは、 leader AKA standby leader は、リモートPostgresノードから複製し、これらの変更をスタンバイクラスターの他のメンバーにカスケードします。

Patroniは、クラスター内の最小数のPostgresノードを必要としますか?

いいえ、Patroniは任意の数のPostgresノードで実行できます。

PatroniはDCSから分離されていることに注意してください。

パトローニで pause はどういう意味ですか?

一時停止はPatroniによって公開される操作であるため、ユーザーはPostgres管理に関してPatroniにステップバックするように要求できます。

これは、クラスターでメンテナンスを実行し、プライマリを停止したときのスタンバイへのフェイルオーバーなど、PatroniがHAに関連する決定を行うことを回避したい場合に役立ちます。

これに関する詳細については、 クラスターの一時停止/再開モード を参照してください。

自動フェイルオーバー

Patroniの自動フェイルオーバーメカニズムはどのように動作しますか?

Patroni自動フェイルオーバーは、 leader race と呼ばれるものに基づいています。

Patroniは、クラスターのステータスをDCSに保存し、その中には、クラスターの現在の leader であるPatroniメンバーの名前を保持する leader ロックを保存します。

その leader ロックには、それに関連付けられた有効期限があります。リーダーノードが leader ロックのリースを時間内に更新できない場合、キーは最終的にDCSから有効期限が切れます。

leader ロックの有効期限が切れると、Patroniが leader race と呼ぶものがトリガーされます。すべてのノードがチェックの実行を開始して、 leader ロールを引き継ぐための最適な候補かどうかを判断します。これらのチェックには、他のすべてのPatroniメンバーのREST APIへの呼び出しが含まれます。

leader ロックを引き継ぐための最適な候補として自分自身を見つけたすべてのPatroniメンバーは、そうしようとします。 leader ロックを取得できる最初のPatroniメンバーは、読み取り/書き込みノードまたは standby leader に昇格し、他のメンバーはそれに従うように構成されます。

Patroniクラスターで自動フェイルオーバーを一時的に無効にすることはできますか?

はい、できます！

これは、クラスターを一時的に一時停止することにより実現できます。これは通常、メンテナンスを実行する場合に役立ちます。

クラスターの自動フェイルオーバーを再開する場合は、一時停止を解除するだけです。

これに関する詳細については、 クラスターの一時停止/再開モード を参照してください。

ブートストラップとスタンバイの作成

PatroniはどのようにプライマリPostgresノードを作成しますか?スタンバイPostgresノードはどうなるでしょうか？

デフォルトでは、Patroniは initdb を使用して新しいクラスターをブートストラップし、 pg_basebackup を使用して leader メンバーのコピーからスタンバイノードを作成します。

カスタムブートストラップメソッド、およびカスタムレプリカ作成メソッドを記述することにより、その動作をカスタマイズできます。

カスタムメソッドは、通常、 pgBackRestやBarmanなどのバックアップツールで作成したバックアップを復元する場合に役立ちます。

詳細については、 ブートストラップ および ブートストラップ を参照してください。

モニタリング

Patroniクラスターをモニタするにはどうすればよいですか?

Patroniは、 Patroni REST API でいくつかの便利なエンドポイントを公開しています。

  • /metrics モニタリングメトリックをPrometheusが使用できる形式で公開します。

  • /patroni クラスターの状態をJSON形式で公開しますここに表示される情報は、 /metrics エンドポイントによって表示されるものと非常に似ています。

これらのエンドポイントを使用して、モニタリングチェックを実装できます。