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ドライバと接続構成。

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

cluster:
  name: mycluster

dcs:
  ...

他のセクションは名前付けたHARPコンポーネントにオプショナルか特定であると考えられるべきです。

クラスター名

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の大部分がまだ残っている限りファンクションし続けます ネットワーク経由で操作可能で到達可能。

コンセンサスレイヤーとしてetcdを使用する場合の形式は次のとおりです。

dcs:
  endpoints:
    - host1:2379
    - host2:2379
    - host3:2379

実験的なbdrコンセンサスレイヤーを使用する場合の形式は次のとおりです。

edb_notranlate_3現在、bdrコンセンサスレイヤーでは、ローカルのpostgresインスタンスを指す最初のエンドポイントが必要です。

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

次のDCS SSL設定は、ドライバ：etcdが構成ファイルで設定されている場合にのみ適用されます。

• ``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ビュー列。英数字 およびアンダースコアのみ。

• ``start_command`` ：これは、DCSの情報の代わりに使用できます 監視するデータベースを起動します。これは、bdrを使用する場合に必要です コンセンサスレイヤー。

• ``status_command`` ：これは、DCSの情報の代わりに使用できます Harp Managerを使用して、データベースが実行されているかどうかを判断します。これは コンセンサスレイヤーとしてbdrを使用する場合に必要です。

• ``stop_command`` ：これは、DCSの情報の代わりに使用できます データベースを停止します。

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

cluster:
  name: mycluster

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

manager:
  name: node1
  log_level: INFO

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

特定のノード設定およびHARP Managerで管理されるノードの初期化の詳細については、 ノードのブートストラップ のセクションをお読みください。

HARPプロキシ固有

一部の構成オプションは、 HARPプロキシに固有です。これらはデーモン自分自身の動作に影響を与えるため、現在config.ymlファイル自分自身に配置されています。

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

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

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

*デフォルト：INFO

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

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

*デフォルト：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ミリ秒前にこのイベントを受信するとします。保証のHARPマネージャーサービスが処理を開始する前にイベントを受信するには、少なくとも5ミリ秒の設定が必要です。

これは、 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つのサービスのみを実行するマイクロアーキテクチャ。

注釈

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

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

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

• ``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`` ：任意の数値。 このオプションが-1に設定されているノードは、harpctlを使用してリードマスターを明示的に設定しようとしても、リードマスターロールを取得できません。

*デフォルト：100

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

*デフォルト：False

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

*デフォルト：250

• ``use_unix_socket`` ： HARP Managerの使用を優先することを指定します データベースに接続するためのUNIXソケット。

*デフォルト：False

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

harpctl set node node1 lease_refresh_interval=100

プロキシディレクティブ

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

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

次の2つのオプションは、ビルトインプロキシを使用する場合にのみ適用されます。

• ``keepalive`` ：ビルトインプロキシがキープアライブメッセージをアイドルリーダー接続に送信するまで待機する秒数。

*デフォルト5

• ``timeout`` ：リーダーへの接続を断念するまでにビルトインプロキシが待機する秒数。

*デフォルト1

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

harpctl set proxy global max_client_conn=1000