よくある質問

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

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

他の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クラスターに関する情報は、Patroni設定の namespace および scope というプレフィックスが付いたパスの下のDCSに保存されます。

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

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

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

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

DCSクラスターを失った場合はどうなりますか?

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

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

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フェールセーフモード を使用すると、この状況を軽減できます。

Patroni

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

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

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

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

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

Patroniリスト で示される情報はDCSの内容に基づいています。

メンバーに関する情報がDCSから消えた場合は、そのノード上のPatroniエージェントが実行されていないか、DCSと通信できない可能性が非常に高くなります。

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

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

Patroniリスト で示される情報はDCSの内容に基づいています。

デフォルトでは、その情報はPatroniによっておよそ loop_wait 秒ごとに更新されます。つまり、すべてが正常に機能している場合でも、DCSに保存されている情報に最大 loop_wait 秒の「遅延」が発生する可能性があります。

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

構成

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

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

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

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

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

種類は次のとおりです。

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

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

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

Note: 一部のPostgresGUCは、グローバルに、つまり動的構成を通じてのみ設定できます。それに加えて、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 リクエストをRESTAPI POST に送信します。または

  • パトロニトルリロード を実行します。または

  • SIGHUP を使用してローカルでPatroniプロセスに信号を送ります。

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

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

Note: Note: によるリロードが機能しない場合があります。

  • 期限切れのRESTAPI証明書: -k の -k オプションを使用することで、これを軽減できます。

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

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

環境設定は、起動時にPatroniによってのみ読み取られます。

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

クラスター内でフェイルオーバーが発生しないように注意してください。 一時停止 をチェックしてみるとよいでしょう。

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

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

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

Patroniは、影響を受けるメンバーに pending restart のフラグを付けます。

メンバーをいつ、どのように再起動するかを決定するのはあなた次第です。これは、次のいずれかの方法で実現できます。

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

Patroni設定における etcd と etcd3 の違いは何ですか?

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

APIバージョン2で保存された情報はAPIバージョン3では管理できず、その逆も同様であることに注意してください。

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

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

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

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

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

Patroni 3.2.0 以降、メンバースロットをPatroniが管理する永久スロットとして持つことができるようになりました。

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

後で、対応するメンバーを削除する場合は、 your responsability で永続スロット構成を調整します。そうでない場合、Patroniはスロットを永久に保持します。

3.2.0 よりも古いPatroniの Note: では、メンバースロットを永続的な物理スロットとして構成できますが、それらは現在のリーダーでのみ管理されます。つまり、フェイルオーバー/スイッチオーバーの場合、これらのスロットは新しいリーダー上に作成されますが、存在しないノードのすべての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 ロックのリース時間を設定します。クラスターの現在のリーダーが ttl を超えてHAサイクル中にリースを更新できない場合、リースは期限切れになり、クラスター内で leader race がトリガーされます。

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

Postgres管理

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

可能ですが、それは避けるべきです。

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

Patroniによる管理を克服するために利用できるオプションがいくつかあります。

  • $PGDATA/postgresql.base.conf を通じてPostgresGUCを変更します。または

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

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

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

いずれの場合も、すべてのPostgres構成をPatroniを通じて管理することをお勧めします。これにより、管理が集中化され、必要なときにPatroniをデバッグしやすくなります。

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

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

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

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

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

はい、できます！

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

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

Patroniは、 pg_ctl や postgres などのPostgresバイナリを実行することにより、Postgresの起動と停止を処理します。

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

概念と要件

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

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

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

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

Patroniの standby cluster とは何ですか?

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

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

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

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

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

Patroniの leader とは何ですか?

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

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

スタンバイPatroniクラスターでは、 leader (別名 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メンバーのRESTAPIへの呼び出しが含まれます。

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

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

はい、できます！

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

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

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

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

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

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

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

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

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

監視

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

Patroniは、 パトローニRESTAPI でいくつかの便利なエンドポイントを公開しています。

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

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

これらのエンドポイントを使用して、監視チェックを実装できます。