Configuring HARP for Cluster Management

HARP構成ファイルは、読みやすくするために簡素化された標準のYAMLスタイルのフォーマットに従います。このファイルはデフォルトで/etc/harpディレクトリにあり、config.yml名前付けです。

-f / --config引数を使用して、構成ファイルの場所をすべてのHARP実行可能ファイルに明示的に提供できます。

標準構成

HARPは基本的に3つのコンポーネントとして動作します。

• HARPマネージャー

• HARPプロキシ

• harpctl

これらはそれぞれ、同じ標準のconfig.yml構成フォーマットを使用します。これには、常に次のセクションが含まれます。

• cluster.name-すべての操作の対象となるクラスターの名前。

• dcs-すべてのエンドポイントのDCSドライバと接続構成。

基本的に、これは標準のプリアンブルがHARPoperationsに常に含まれ、これに似ていることを意味します。

cluster:
   * name: mycluster

dcs:
   * ...

他のセクションは、オプショナルまたは指定された名前付けに固有のものと見なされる必要があります。

クラスター名

HARPとの相互作用には、cluster見出しの下の** name **エントリーが必要です。各HARPクラスターには、明確化の目的と、特定のクラスターのDCS内のデータのラベル付けの両方の名前があります。

HARPマネージャーは、 HARPプロキシとharpctlが使用するクラスターに関する情報をここに書き込みます。 HARPプロキシサービスは、このクラスター内のノードにトラフィックを誘導します。 harpctl管理ツールは、このクラスターと対話します。

DCS設定

コンセンサスレイヤーの構成は、 HARP機能のキーとなります。 DCSがなければ、 HARPにはクラスターメタデータを格納する場所がなく、リーダーシップ選挙を行うことができません。したがって、構成のこの部分は必須ですが、特定の要素はオプショナル。

すべての要素は、dcs名前付けのセクションの下に、ここで説明するマルチプルの補足エントリとともに指定する必要があります。

• ** driver **：使用する必須コンセンサスレイヤーのタイプ。 現在はetcdまたはbdrになります。コンセンサスレイヤーとしてのbdrのサポートは 実験的。コンセンサスレイヤーとしてbdrを使用すると、 コンセンサスストレージ用の追加ソフトウェア、ただし最低3つが必要 データベースのメンテナンス中にクォーラムを維持するための完全なBDRメンバノード。

• ** endpoints **：DCSに接続するために必要な接続文字列のリスト。 可能であれば、DCSのすべてのノードをここにリストする必要があります。これにより、 HARP DCSの大部分がまだ残っている限りファンクションし続けます ネットワーク経由で操作可能で到達可能。

• ** request_timeout **：リクエストが失敗したとみなす時間（ミリ秒）。 HARPがDCSに要求を行い、この時間内に応答を受信しない場合 期間は、オペレーションが失敗したと見なす必要があります。これにより問題が発生する可能性があります リクエストの性質に応じて、エラーとして記録されるか、再試行されます。 デフォルト：250。

• ** ssl **：onまたはoffのいずれかで、DCSとのSSL通信を有効にします。

  • デフォルト：off

• ** ssl_ca_file **：クライアントSSL認証局（CA）ファイル。

• ** ssl_cert_file **：クライアントSSL証明書ファイル。

• ** ssl_key_file **：クライアントSSLキーファイル。

例

次に、3つのノードで構成されるetcd DCSに接続するようにHARPを構成する方法の例を示します。

dcs:
   * driver: etcd
   * endpoints:
   *   - host1:2379
   *   - host2:2379
   *   - host3:2379

HARPマネージャー固有

すべてのHARPコンポーネントに必要な汎用サービスオプションに加えて、Managerは少なくとも1つ以上の設定が必要です。

• ** log_level **：DEBUG、INFO、WARNING、ERROR、またはCRITICALのいずれか HARPサービスからのログ出力の量を変更する可能性があります。

• ** name **：このマネージャーが表すPostgresノードの必須名前。 Managerは特定のノードのみを表すことができるため、そのノードにはここで名前が名前付け、 このマネージャーに名前を付ける役割も果たします。これがBDRノードである場合、マッチする必要があります 実行時にノード作成時に使用される値 bdr.create_node(node_name, ...)ファンクションおよび bdr.local_node_summary.node_nameビュー列。英数字 およびアンダースコアのみ。

したがって、 HARP Managerの完全な構成例は次のようになります。

cluster:
   * name: mycluster

dcs:
   * driver: etcd
   * endpoints:
   *   - host1:2379
   *   - host2:2379
   *   - host3:2379

manager:
   * name: node1
   * log_level: INFO

これは基本的にDCS連絡先情報、関連するサービスのカスタマイズ、クラスター自分自身の名前、およびノードの名前であることに注意してください。他のすべての設定はノード自分自身に関連付けられ、DCS内に保存されます。

特定のノード設定と、 HARPマネージャーによって管理されるノードの初期化の詳細については、Node Bootstrappingのセクションをお読みください。

HARPプロキシ固有

一部の構成オプションは、 HARPプロキシに固有です。これらは、デーモン自分自身に配置されています。

プロキシベースの設定はproxy見出しの下で指定でき、次のものが含まれます。

• ** location **：ロケーションHARPプロキシの必須名前が表す必要があります。 HARPプロキシノードは、次のように、実行されている場所に直接関連付けられます。 それらは常にトラフィックを現在のLead Masterノードに向けます。これは 定義されたプロキシに指定されます。

• ** log_level **：DEBUG、INFO、WARNING、ERROR、またはCRITICALのいずれか HARPサービスからのログ出力の量を変更する可能性があります。

  • *デフォルト：INFO

• ** name **：この特定のプロキシの名前。 各プロキシノードには、関連する統計または動作を保証名前が名前付けます 状態は、ステータスチェックおよびその他のインタラクティブイベントで使用できます。

• ** type **：pgbouncerまたは実験的シンプル通過地点プロキシを使用するかどうかを指定します。すべてのプロキシは同じプロキシタイプを使用する必要があります。実験的なBDR DCSと組み合わせて、シンプルプロキシのみで実験することをお勧めします。 pgbouncerまたはsimpleproxyの場合があります。

• デフォルト：pgbouncer

• ** pgbouncer_bin_dir **：PgBouncerバイナリが置かれているディレクトリ。 HARPはPgBouncerバイナリを利用するため、これらがどこにあるかを知るニーズがあります あります。これはプラットフォームまたはディストリビューションに依存する可能性があるため、 デフォルト仮定は、適切なバイナリが それ以外の場合は、環境のPATH変数。

例

HARPプロキシには、オペレーション中のプロキシのクラスター名前、DCS接続設定、場所、および名前が必要です。以下に例を示します。

cluster:
   * name: mycluster

dcs:
   * driver: etcd
   * endpoints:
   *   - host1:2379
   *   - host2:2379
   *   - host3:2379

proxy:
   * name: proxy1
   * location: dc1
   * pgbouncer_bin_dir: /usr/sbin

他のすべての属性は、プロキシのスタートアップにDCSから取得されます。

実行時ディレクティブ

config.ymlファイルでYAMLの最小値を使用してHARP Manager、 HARP Proxy、またはharpctlを構成することは可能ですが、一部のカスタマイズはDCS内で保持され自分自身。これらの値は、ブートストラップを介して初期化するか、harpctl set指示子で特定に設定する必要があります。

このセクションでは、これらの概要と、それらの指定方法について説明します。

クラスター全体

ここでの設定は、ブートストラップ中にcluster YAML見出しの下で設定するか、harpctl set clusterコマンドで変更する必要があります。

• ** event_sync_interval **：同期を待機する時間（ミリ秒）。 HARP内でイベントが発生すると、クラスター全体で非同期的に発生します。 HARP Managerは、メタデータの変更を検出するとすぐに動作をスタートし、 また、 HARPプロキシはトラフィックを一時停止し、エンドポイントの再構成をスタートする場合があります。これは の最大量にほぼ近似することを意図した安全インターバル すべてのHARPコンポーネント間に存在する可能性があるイベント時間のスキュー。

例、ノードAがオフラインになり、ノードBのHARPマネージャーが一般的になるとします ノードCの5ミリ秒前にこのイベントを受信します。少なくとも5ミリ秒の設定 その後、保証のHARP Managerサービスが 処理を開始する前のイベント。

• これは、 HARPプロキシにも適用されます。

ノードディレクティブ

ノード指向の設定のほとんどは、 HARPマネージャーがアクティブなときに変更して適用できます。これらの項目は、初期ブートストラップ後にDCSに保持されるため、構成ファイルを変更せずに変更できます。

ここでの設定は、ブートストラップ中にnode YAML見出しの下で設定するか、harpctl set nodeコマンドで変更する必要があります。

• ** camo_enforcement **：CAMOキューの状態を厳密に実施するかどうか。 strictに設定すると、 HARPはBDRへのスイッチオーバーまたはフェイルオーバーを許可しません。 CAMOパートナーノードは、CAMOキュー全体に完全に追いついていない限り 移行の時間。 lag_onlyに設定すると、標準ラグのみ maximum_camo_lagなどのしきい値が適用されます。

• ** dcs_reconnect_interval **：切断されたノードがDCSへの再接続を試行するインターバル（ミリ秒単位）。

  • *デフォルト1000

• ** dsn **：管理対象Postgresノードへの完全な接続文字列が必要です。 このパラメータはすべてのHARPサービスに等しく適用され、有効にします コンテナごとに1つのサービスのみを実行するマイクロアーキテクチャ。

  • !!! Note

  • HARPはデフォルトでsslmode引数をrequireに設定し、SSLを必要としないサーバーへの接続を防ぎます。この動作を無効にするには、このパラメータをdisable、allow、preferなどのより許容度の高い値に明示的に設定します。

• ** db_data_dir **：必須のPostgresデータディレクトリ。 これは、 HARP ManagerがPostgresをスタート、停止、またはリロードするために必要です。 サービスまた、構成ファイルのデフォルトの場所でもあります。 ストリーミングレプリカのプロモーションを制御するために後で使用される。

• ** db_conf_dir **： Postgres構成ファイルの場所。 一部のプラットフォームでは、 Postgres構成ファイルを Postgresデータディレクトリ自分自身。これらの場合、これはそれに設定する必要があります 予想される場所。

  • デフォルト``db_data_dir``-``db_log_file``： Postgresログファイルの場所。デフォルト/tmp/pg_ctl.out

• ** イベント **： HARPがDCSに到達できない場合、いくつかの準備キーとリーダーシップリース自分自身がエキスパイアになります。これにより、ノードがルーティングを考慮することを暗黙的に防ぎます。ただし、そのようなノードは公式にフェンスされておらず、stop_database_when_fencedがfalseに設定されている場合、マネージャはデータベースのモニタリングを停止しません。

  • *デフォルト：False-``leader_lease_duration``：更新されない場合、リードマスターリースが保持される秒単位の時間。これにより、 HARPマネージャーは特定の猶予期間でロックをリフレッシュできます。有効期限が切れると、代わりに別のノードがリードマスターロックを取得できます。

  • *デフォルト：30

• ** lease_refresh_interval **：ミリ秒単位の時間 リードマスターリースの更新。これは本質的に時間を制御します HARP Managerがその割り当てに対して実行する各シリーズのチェックの間 Postgresノード、およびコンセンサスでノードのステータスが更新されたとき レイヤー

  • *デフォルト：5000- ``max_dcs_failures``：fence_node_on_dcs_failureに従ってフェンスされたノードとしてマーキングする前のDCS要求の失敗の量。これにより、一時的な通信の中断によるデータベースノードのシャットダウンが防止されます。

  • *デフォルト：10-``maximum_lag``：リードマスターロックの取得が許可される前の、前回のリードマスターとこのノードの最後に記録されたLSN間の最大許容分散（バイト単位）。これにより、ターミナル的な遅延が発生しているノードがリードマスターロックを取得できなくなります。このチェックを無効にするには、-1に設定します。

  • *デフォルト：1048576（1MB）

• ** maximum_camo_lag **：最後の最大許容分散（バイト単位） このノードとそのCAMOパートナー間でLSNを受信し、LSNを適用しました。 これは、CAMOが使用可能で有効になっているクラスターにのみ適用する必要があります。 したがって、これはpg2q.enable_camoが設定されているBDR EEクラスターにのみ適用されます。 特に厳しいCAMO適用キュー制限のあるクラスターを設定する必要があります これは非常に低いか、適用されていないCAMOトランザクションを回避するために0までです。に設定 このチェックを無効にするには-1。

  • *デフォルト：1048576（1MB）

• ** ready_status_duration **：ノードの準備ができている時間（秒） 更新されない場合、ステータスは持続します。これはフェイルセーフであり、 HARPマネージャーが担当している場合、 HARPプロキシがノードに連絡しない 動作を停止します。

  • *デフォルト：30

• ** db_bin_dir **： Postgresバイナリが置かれているディレクトリ。 HARPはpg_ctlなどのPostgresバイナリを利用するため、どこでそれを知るニーズがあります これらがあります。これはプラットフォームまたはディストリビューションに依存する可能性があるため、 デフォルト仮定は、適切なバイナリが それ以外の場合は、環境のPATH変数。

• ** priority **：0以上の任意の数値。 2つのノードに等量の遅延があり、他のノードが適格である場合 リードマスターリースを取得する基準。これは追加のランキングとして機能します。 あるノードを別のノードに優先させる値。このオプションが設定されているノード 0にすると、マスターマスターのロールを引き受けることができなくなります。 harpctlを使用してリードマスターを明示的に設定します。

  • *デフォルト：100

• ** safety_interval **：ルーティングを許可するまでのミリ秒単位の時間 新しく昇格したリードマスターに。これは、自動化されたチェックを許可することを目的としています 新規移行する前に、 HARPルーターに対してクラスター全体で障害が発生する 昇格されたノードへの接続。これにより、完全な同期を強制できます ルーティングターゲット。無効にするには0。

  • *デフォルト：100

• ** stop_database_when_fenced **：考えられるすべてのルーティングからノードを単に削除するのではなく、ノードがフェンスされたときにデータベースを停止します。これは、 HARPプロキシ以外のソースからのデータがデータベースに到達しないようにするための、またはプロキシが他の何らかの理由でクライアントを切断できない場合の追加の安全対策です。

  • *デフォルト：False-``consensus_timeout``：コンセンサスレイヤーへの読み取りまたは書き込みを中止するまでのミリ秒数。コンセンサスレイヤーがクォーラムを失うか、到達不能になったイベント、無限のタイムアウトではなく、ほぼ瞬時のエラーが必要です。これにより、このような場合のブロック動作が防止されます。注：bdrをコンセンサスレイヤーとして使用する場合、認識される最大のタイムアウトは1000ミリ秒です。

  • *デフォルト：250

これらの実行時指示子はすべて、harpctlを介して変更できます。 node1でlease_refresh_intervalを100ミリ秒に減らしたいかどうかを検討します。

harpctl set node node1 lease_refresh_interval=100

プロキシディレクティブ

サービスがアクティブなときにプロキシの特定の設定を変更できます。これらの項目は、初期ブートストラップ後にDCSに保持されるため、構成ファイルを変更せずに変更できます。これらの設定の多くは、同等のPgBouncerへの直接マッピングであり、関連する場合はこれらにノートします。

ここでの設定は、ブートストラップ中にproxies YAML見出しの下で設定するか、harpctl set proxyコマンドで変更する必要があります。

• ** auth_file **：PgBouncerスタイルのuserlist.txtファイルへのフルパス。 HARPプロキシはこのファイルを使用して、pgbouncerユーザを保存します。 PgBouncerの管理データベースへのアクセス。このファイルは他のユーザーに使用される場合があります 同様に。プロキシはこのファイルを変更して、パスワードを追加および変更します pgbouncer ユーザ。

  • *デフォルト/etc/harp/userlist.txt

• ** auth_type **：パスワードに使用するPostgres認証の種類 マッチングこれは実際にはPgBouncer設定であり、完全には互換性がありません Postgres pg_hba.conf機能を使用します。 md5、pamの使用をお勧めします cert、またはscram-sha-256。

  • *デフォルトmd5

• ** auth_query **： Postgresでユーザーのパスワードを確認するクエリ。 pg_shadowに直接アクセスするには、管理者権限が必要です。を使用することをお勧めします 代わりにSECURITY DEFINERファンクションを呼び出す非スーパーユーザー。使用する場合 クラスターを作成するTPAexec、pgbouncer_get_auth名前付けのファンクションは これを満たすために、pg_catalog名前空間内のすべてのデータベースにインストールされます 目的。

• ** auth_user **：auth_userが設定されているユーザ、 auth_fileは、pg_shadowからのauth_queryクエリーを介してクエリされます auth_userを使用したデータベース。 auth_userのパスワードは auth_fileから取得。

• ** client_tls_ca_file **：クライアントを検証するためのルート証明書ファイル 証明書。 client_tls_sslmodeを設定する必要があります。

• ** client_tls_cert_file **：プライベートキーの証明書。クライアントはできます それを検証します。 client_tls_sslmodeを設定する必要があります。

• ** client_tls_key_file **：PgBouncerがクライアントを受け入れるための秘密キー 接続。 client_tls_sslmodeを設定する必要があります。

• ** client_tls_protocols **：使用できるTLSプロトコルバージョン クライアント接続。 許可される値：tlsv1.0、tlsv1.1、tlsv1.2、tlsv1.3。 ショートカット：all（tlsv1.0、tlsv1.1、tlsv1.2、tlsv1.3）、 secure（tlsv1.2、tlsv1.3）、legacy（すべて）。

  • *デフォルトsecure

• ** client_tls_sslmode **：クライアントSSL機能を有効にするかどうか。

  • disable allow prefer require verify-ca verify-fullのいずれかです。

  • *デフォルトdisable

• ** database_name **：データベースクライアントを表す必須の名前 HARPプロキシに接続するときに使用します。これは安定（stable）エンドポイントであり、 変更せず、現在のノード、データベース名前、ポートなどを指します。 リードマスターに接続するために必要です。グローバル値*を使用できます ここで、データベースに関係なく、すべての接続がこのターゲットに向けられます 名前

• ** default_pool_size **：許可するアクティブな接続の最大量 データベース/ユーザの組み合わせごと。これはコネクションプーリングを目的としていますが、 しかし、セッションプーリングモードでは何もしません。これはPgBouncer設定です。

  • *デフォルト25

• ** ignore_startup_parameters **：デフォルトでは、PgBouncerは スタートアップパケットで追跡できるパラメーター：client_encoding、 datestyle、timezone、およびstandard_conforming_strings。他のすべて パラメータはエラーを発生させます。他のパラメーターを許可するには、 PgBouncerが管理者によって処理されていることを認識できるように、ここで指定します それらは無視できます。多くの場合、これを設定する必要があります Javaアプリケーションが正しくファンクションするためのextra_float_digits。

  • *デフォルトextra_float_digits

• ** listen_address **：プロキシが監視するするIPアドレス 接続。これはPgBouncer設定です。

  • *デフォルト0.0.0.0

• ** listen_port **：プロキシが接続を監視するするシステムポート。 これはPgBouncer設定です。

  • *デフォルト6432

• ** max_client_conn **：アクティブなクライアントの合計最大量 プロキシで許可される接続。これは、多くの注文になります これらはすべてdefault_pool_sizeより大きい接続であるため、 セッションがまだ割り当てられていない、または使用するためにセッションをリリースしている 別のクライアント接続。これはPgBouncer設定です。

  • *デフォルト100

• ** monitor_interval **：PgBouncerのプロキシチェック間の秒単位の時間。 HARP Proxyは実際の接続管理としてPgBouncerを管理するため レイヤー、さまざまなステータスと統計を定期的にチェックして確認するニーズがあります まだ運用中です。この情報の一部はログに記録されるか、 DCSに登録されています。

  • *デフォルト5

• ** server_tls_protocols **：使用できるTLSプロトコルバージョン サーバー接続。 許可される値：tlsv1.0、tlsv1.1、tlsv1.2、tlsv1.3。 ショートカット：all（tlsv1.0、tlsv1.1、tlsv1.2、tlsv1.3）、 secure（tlsv1.2、tlsv1.3）、legacy（すべて）。

  • *デフォルトsecure

• ** server_tls_sslmode **：サーバーSSL機能を有効にするかどうか。

  • disable allow prefer require verify-ca verify-fullのいずれかです。

  • *デフォルトdisable

• ** session_transfer_mode **：セッションを転送する方法。

  • fast wait reconnectのいずれかです。

  • *デフォルトwait

• ** server_transfer_timeout **：HarpプロキシがPAUSEをあきらめてKILLコマンドを発行するまで待機する秒数。

  • *デフォルト30

harpctlを使用してすべてのプロキシのこれらの設定を変更する場合、プロキシ名前の代わりにglobalキーワードを使用します。例：

harpctl set proxy global max_client_conn 1000