Patroni cluster management commands

Patroni cluster management commands#

Patroniは、次のコマンドオプションを使用して、M1アーキテクチャでシングルマスターフェールオーバーマネージャーとして使用できます。

tpaexec configure cluster_name -a M1 --enable-patroni --postgresql 14

またはconfig.ymlオプションを設定することにより

cluster_vars:
  failover_manager: patroni

TPAは、 patroni パッケージPGDGリポジトリからまたはedb-patroni パッケージEDBリポジトリからを使用してPatroniクラスターを展開できます。これは、 config.ymlのcluster_vars の下のpatroni_package_flavour オプションを介して構成できます。これは、 --patroni-package-flavour コマンドライン引数を介して設定することもできます。 patroni_package_flavour が明示的に設定されていない場合、TPAは、構成されたリポジトリに基づいてフレーバーを推論しようとします。EDBリポジトリが構成されている場合、暗黙的にedb フレーバーを選択し、それ以外の場合は暗黙的にcommunity フレーバーを選択します。

TPA configure は3つのetcdノードを追加し、オプション --enable-haproxy を指定する場合2つのhaproxyノードを追加する場合があります。 etcdは、分散構成ストアDCSに使用されます。 Patroniは他のDCSバックエンドをサポートしていますが、現在EDBまたはTPAではサポートされていません。

HAProxyの代替として、--enable-pgbouncer オプションを使用して、PostgresノードでPgBouncerを構成できます。 PgBouncerは、プライマリの接続をプールするように構成されます。 Patroniは、クラスター内のフェールオーバーまたはスイッチオーバー時にPgBouncerを再構成するように構成されるため、PgBouncerは新しいプライマリPostgresインスタンスに従います。

TPAは、既存のPostgreSQLクラスターを変換するPatroniの機能を使用します。これにより、TPAは構成を初期化および管理できます。 PostgreSQLクラスターが作成されると、Patroniが管理を引き継ぎます。 TPAは、セットアップ中に使用されたpostgres構成ファイルを削除します。

セットアップが完了すると、クラスターのTPAとconfig.yml の設定を使用して、Postgresを引き続き管理できます。コマンドライン patronictl やREST APIなどのPatroniインターフェイスを使用することもできますが、可能な限りTPAメソッドを使用することをお勧めします。

Patroniパッケージバージョン#

デフォルトでは、TPAはPatroniの最新バージョンをインストールします。

インストールされるPatroniパッケージのバージョンは、 config.yml ファイルのcluster_vars セクションの下のpatroni_package_version: xxx を含めることにより指定できます。

cluster_vars:
    …
    patroni_package_version: 4.0.0-1PGDG.rhel8`
    …

aptまたはyumが受け入れるバージョン指定子を使用できます。

バージョンが一致しない場合は、 * ワイルドカードを追加してみてください。これは、パッケージバージョンに2:... のようなエポック修飾子がある場合に必要になることがよくあります。

これらの構成変数は、TPAでのPatroniの展開での特定の動作を制御するために使用できます。

Variable

Default value

Description

patroni_super_user

postgres

スーパーユーザーロールのpostgresで作成するユーザー。

patroni_replication_user

replicator

レプリケーションロールのpostgresで作成するユーザー名。

patroni_restapi_user

patroni

patroni REST API用に構成するユーザー名。

patroni_rewind_user

rewind

pg_rewindファンクションのpostgresで作成するユーザー名。

patroni_installation_method

pkg

パッケージまたはソースたとえばgitリポジトリまたはdockerの場合はローカルソースディレクトリなどからpatroniをインストールします。

patroni_package_flavour

community if no EDB repository is configured, else edb

`edb-patroni`パッケージ `edb`フレーバー、EDBリポジトリが必要 または `patroni`パッケージ `community`フレーバー、PGDGおよびEPEL RedHatベースのみのリポジトリが必要 をインストールするかどうか。

patroni_ssl_enabled

no

REST APIおよびctl接続のSSLを有効にするかどうか。可能な場合は、クラスターSSL証明書とCAを使用します。

patroni_rewind_enabled

yes

postgres rewindを有効にするかどうか、patroni_rewind_userで定義されたユーザーを作成し、configセクションを追加します。

patroni_watchdog_enabled

no

追加のスプリットブレイン防止のためにカーネルウォッチドッグを構成するかどうか。

patroni_dcs

etcd

DCSに使用するバックエンド。現時点ではetcdのみがオプションです。

patroni_listen_port

8008

REST API TCPポート番号

patroni_conf_settings

{}

パトローニ構成のオーバーライドを含む構造化データオブジェクト。部分的なデータを提供でき、生成された構成とマージされます。実行時に既知のインスタンス情報に基づいて生成された値をオーバーライドしないように注意してください。

patroni_dynamic_conf_settings

{}

DCS設定専用のオプションの構造化データ。これは`patroni_conf_settings`にマージされます。

patroni_repl_max_lag

None

これは、haproxy_read_only_load_balancer_enabled`がtrueの場合にのみhaproxyバックエンドヘルスチェックで使用されます。 `/replica?lag`の可能な値については、 :ref:`Configuring lvm-direct for production <Patroni cluster management commands> を参照してください

Patroni構成ファイル設定#

patroniの構成は3つのレイヤーから構築され、Patroniデーモンによって設定されたデフォルトから始まり、DCSからロードされた構成、最後にローカル構成から構築されます。最後は、構成ファイルから制御でき、環境を介してオーバーライドできます。 TPAは構成ファイルを制御し、値はこの順序で構築されます。

APIに送信され、構成ファイルのブートストラップセクションに保存されるDCS構成。

  • postgres のTPA変数はDCS設定にロードされます。 postgresql.conf を参照してください。一部の機能はサポートされていません。以下の注意事項を参照してください。

  • DCS設定のPatroniのデフォルト

  • patroni_dynamic_conf_settings のユーザー指定のデフォルト。DCS設定をオーバーライドする場合は、ここで行うことができます。

YAML構成ファイルに保存されるローカル構成

  • 上記の前の手順からロードされたbootstrap.dcs 。

  • patroni_ssl_enabled などの機能フラグによって有効になる構成。上記の表を参照してください。

  • 次に、最後にユーザー指定設定からオーバーロードされますpatroni_conf_settings オプション。機能フラグによって制御されない構成を変更または追加する場合、これはそれに最適な場所です。

構成は、IPアドレス、ポート番号、クラスターロールなどのクラスター情報からTPAによって生成された構成に マージ されることに注意してください。これは、クラスターの安定したオペレーションに影響を与える可能性があるため、オーバーライドするものに注意してください。

Patroniはすべてのpostgres構成をDCSに保存し、これがpostgresに配布される方法と時期を制御するため、TPAの一部の機能はpatroniと互換性がありません。

  • postgres_conf_template 設定でpostgresql.conf の生成に使用されたテンプレートを変更することはできません。

  • 設定postgres_conf_dir では、Postgres構成ファイルの場所を変更することはできません。

TPAのPatroni構成 config.yml#

単一の値をオーバーライドできます。

cluster_vars:
  patroni_conf_settings:
    bootstrap:
      dcs:
        ttl: 120

またはフルブロックPatroniドキュメントからの例を使用して

cluster_vars:
  patroni_conf_settings:
    restapi:
      http_extra_headers:
        X-Frame-Options: SAMEORIGIN
        X-XSS-Protection: 1; mode=block
        X-Content-Type-Options: nosniff
      https_extra_headers:
        Strict-Transport-Security: max-age=31536000; includeSubDomains

デフォルトのTPA構成変数に存在する値またはセクションを無効にする場合は、値をnull に設定できます。これにより、パトロニは、構成ファイルをロードするときにこのセクションを無視します。

たとえば、log のデフォルトのTPA構成は次のとおりです。

log:
  dir: /var/log/patroni

ロギングをオフにするには、これをconfig.yml に追加します。

cluster_vars:
  patroni_conf_settings:
    log: null

TPAは、Patroniクラスターを管理するためのこれらの最小限のツールセットを提供します。

ステータス#

Patroni実行に従ってTPAクラスターの現在のステータスを確認するには

tpaexec status cluster_name

スイッチオーバー#

レプリカノードへのスイッチオーバーを実行するにはメンテナンスを実行するには、次のコマンドを実行します。

tpaexec switchover cluster_name new_primary

new_primary引数は、現在正常なレプリカとして実行されている既存のクラスターノードの名前である必要があります。スイッチオーバーが実行される前に、これがtrueを確認するためにチェックが実行されます。

スイッチオーバーが実行されたら、 deploy およびtest を実行して、正常なクラスターを確認することをお勧めします。

tpaexec deploy cluster_name
tpaexec test cluster_name

TPAは、config.ymlの内容に関係なく、展開中にノードの現在のロールを検出しますたとえば、別のノードがリーダーである場合。

目次