HARP Proxy¶

HARPプロキシは、クライアントアプリケーションとPostgres間の抽象化レイヤーとして機能するデーモンです。コンセンサスレイヤーとインターフェイスして、現在のリードマスターノードのIDを取得し、その場所にトラフィックを転送します。計画的なスイッチオーバーまたは計画外のフェイルオーバーが発生したイベント、DCSの指示に従って、新しいリードマスターノードに自動的にリダイレクトされます。

このHARPコンポーネントは現在、DCSとPgBouncer間のインタフェースレイヤーです。そのオーダー、 HARPプロキシがアクティビティを完全に管理するには、PgBouncerが前提条件であり、さらにインストールする必要があります。

仕組み¶

HARPプロキシは、起動時にPgBouncerをまだ実行していない場合は起動し、クライアント接続を一時停止状態のままにします。その後、DCSに接続してリードマスターのIDを特定し、これをデータベース接続のターゲットとして使用するようにPgBouncerを構成し、接続アクティビティを再開します。すべてのアプリケーションクライアントトラフィックは、PgBouncerを通過して、このプロキシが動作している場所の現在のリードマスターノードに到達します。

PgBouncerの実行中、 HARPプロキシはDCS内のmonitor_interval構成設定に基づいてそのステータスを確認し、モニタリングのためにDCSに保存します。これにより、harpctlを使用して、構成されているすべてのプロキシ、または特定のプロキシのステータスを取得できます。

Lead Masterリースが設定されていないイベント、 HARP Proxyは、新しいLead Masterが確立されるまで、すべての接続トラフィックを一時停止します。これは、harpctl promoteを使用して、新しいリードマスターへの計画的な移行を呼び出す場合にも適用されます。このためにPgBouncer PAUSEコマンドを使用するため、既存のセッションは、停滞する前に保留中のトランザクションを完了できます。

設定¶

HARPプロキシは、dcs、cluster、およびproxy構成スタンザを想定しています。以下は機能的な例です。

cluster:
   * name: mycluster

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

proxy:
   * name: proxy1

使用法¶

これは、 HARPプロキシの基本的な使用法です。

Usage of ./harp_proxy:
   * -f string
   *    Optional path to config file (shorthand)
   * --config string
   *    Optional path to config file

フォークされたデーモンとしてharp_proxyを起動する引数がないことに注意してください。このソフトウェアは、systemdを介して、または最上位プロセスとしてコンテナ内で起動するように設計されています。これは、journaldまたは接続されたコンテナターミナルを介したキャプチャおよびアクセスのために、出力がSTDOUTおよびSTDERRに向けられることも意味します。

PgBouncer構成ファイル¶

HARPプロキシは現在、接続管理とリダイレクトにPgBouncerを利用しているため、pgbouncer.iniファイルが存在する必要があります。 HARP Managerは、Proxy Directivesの文書で定義されているさまざまな実行時指示子に基づいてこのファイルを構築します。

このファイルは、HARPProxyが使用するconfig.ymlと同じフォルダーに配置されます。 HARPプロキシによって起動されたPgBouncerプロセスは、この構成ファイルを使用し、デバッグまたは情報目的に使用できます。この自動生成されたpgbouncer.iniファイルへの変更は、HARPプロキシが再起動されるたびに失われるため、代わりにharpctl set proxyを使用してこれらの設定を変更します。

HARPプロキシノード管理の無効化と再有効化¶

PgBouncerのHARPプロキシ制御を一時的に一時停止することができます。これにより、デーモンの実行は継続されますが、クラスターの既存の動作に影響を与える可能性のある操作は実行されません。管理を再度有効にすると、オペレーションが再開されます。

特定のプロキシの管理を一時的に無効にする例は次のとおりです。

harpctl unmanage proxy proxy1

詳細については、harpctlの文書を参照してください。

プロキシノード管理はデフォルトで有効になっています。

パススルーユーザー認証¶

auth_userおよびauth_queryランタイム指示子を使用するようにHARPプロキシを構成することを強くお勧めします。これらが設定されていない場合、PgBouncer userlist.txtファイルには、PgBouncerがPostgresに代わって認証するニーズがあるすべてのユーザのユーザー名とパスワードのハッシュの組み合わせを含める必要があります。

これは、基になるPgBouncerサービスを操作するオーダーに管理レベルのユーザとしてHARPプロキシによって利用されるため、pgbouncerユーザ自分自身ではないはずです。

TPAexecによって管理されるクラスターでは、プロビジョニング中にファンクションが作成され、template1データベースのpg_catalogスキーマにインストールされます。これは、その後に作成されるデータベースにもファンクションが含まれ、ユーザがどのデータベースに接続しようとしているかに関係なく、PgBouncerで利用できることを意味します。

TPAexecを使用しない場合でも、次のファンクション定義をお勧めします。

CREATE OR REPLACE FUNCTION pg_catalog.pgbouncer_get_auth(p_usename TEXT)
RETURNS TABLE(username TEXT, password TEXT) AS $$
BEGIN
   * RETURN QUERY
   * SELECT usename::TEXT, passwd::TEXT FROM pg_catalog.pg_shadow
   *  WHERE usename = p_usename;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER

REVOKE ALL ON FUNCTION pg_catalog.pgbouncer_get_auth(p_usename TEXT)
   * FROM PUBLIC

GRANT EXECUTE ON FUNCTION pg_catalog.pgbouncer_get_auth(p_usename TEXT)
   *  TO <auth_user>;

HARPプロキシに提供されるauth_userフィールドを<auth_user>に置き換えることを忘れないでください。

次に、Bootstrapファイルで、次の設定を完了します。

cluster:
   * name: mycluster

proxies:
   * monitor_interval: 5
   * default_pool_size: 20
   * max_client_connections: 1000
   * auth_user: pgb_auth
   * auth_query: "SELECT * FROM pg_catalog.pgbouncer_get_auth($1)"
   * database_name: bdrdb
   * instances:
   *   - name: proxy1
   *   - name: proxy2

harpctl set proxyを使用してこれらのフィールドを定義することもできます。

harpctl set proxy global auth_user=pgb_auth

!!! Note * これは、 HARPプロキシを起動するpostgresまたはenterprisedb OSユーザが、auth_userがPostgresに対して認証できるように.pgpassファイルが必要であることを意味します。