Configuring connection pooling

Configuring connection pooling#

PGDノードグループの Connection Manager Authentication の接続プーリングを有効にして、クライアント間でサーバー接続をリサイクルすることによりデータベースのスループットを最大化し、多くの短期間の接続を使用するアプリケーションからの接続スパイクを防ぎます。 Connection Managerのビルトイントランザクションプーリングでは、追加のソフトウェアを展開または保守する必要はありません。

各プールモードで正常に動作するアプリケーションを作成するためのガイダンスについては、 Using connection pooling in your application を参照してください。

前提条件#

  • 各データノードPGD 6.4以降で実行されている接続マネージャー。 Monitoring the Connection Manager を参照して、実行されていることを確認します。

  • bdr_superuser ロールまたはrunと同等のロール bdr.alter_node_group_option

接続プーリングの有効化#

接続プーリングはデフォルトで無効になっており、server_pool_mode はnone に設定されています。これを有効にするには、ノードグループのモードをsession またはtransaction に設定します。

SQLを使用する

SELECT bdr.alter_node_group_option(mygroup, server_pool_mode, transaction);

PGD CLIを使用する

pgd group mygroup set-option server_pool_mode transaction

プーリングを有効にしても、既存の接続は影響を受けず、新しい接続のみが更新されたモードを使用します。 transaction モードから切り替える場合、オープンなトランザクションのない既存のクライアント接続は、次回トランザクションを開始したときに閉じられます。

接続は長くなりますが、トランザクションは短く、間にアイドル時間がある場合、たとえば、クライアントアプリケーションが独自の接続プーリングを使用する場合、 transaction モードを使用します。

持続期間の短い接続、またはアプリケーションがトランザクション全体で持続するセッション状態に依存している場合 SET 、一時テーブル、またはアドバイザリロックなど session モードを使用します。各モードの詳細については、 Connection pooling を参照してください。

警告

デフォルトでは、トランザクションモードは、各トランザクションの終了にほとんどのセッション状態をリセットします。有効にする前に、WITH HOLD カーソル、LISTEN 、または`SET` 変更など、トランザクション全体でセッション状態を持続する必要がある機能に依存するアプリケーションがあるかどうかを開発チームに確認してください。影響を受ける機能の完全なリストについては、 Using connection pooling in your application を参照してください。スループットを向上させるために`server_reset_mode` グループオプションを`fast` に設定すると、そのリセットは保証されません。同じアプリケーションは同じレビューを必要としますが、予想通りに失敗する代わりに、あるクライアントが別のクライアントが残したセッション状態をサイレントに見る危険があります。 リセットモードの構成 を参照してください。

アクティブなプールモードを確認します。

SELECT node_group_name, server_pool_mode FROM bdr.node_group_summary;

プールのモニタリング#

Monitoring the Connection Manager は、アクティブな接続とプールの使用率を追跡するために使用可能なメトリックとHTTPエンドポイントについて説明します。

pgBouncerからの移行#

Connection Managerはビルトインの接続プーリングを提供し、pgBouncerなどの別個のプーラーの必要を排除します。そのプーリングモードは、pgBouncerのセッションおよびトランザクションプーリングモードに似ています。移行するには、次の手順に従ってください。

  1. 現在のpgBouncerプールモード session またはtransaction と一致するようにserver_pool_mode を設定します。

  2. pgBouncerのtransaction プールモードから移行する場合は、server_reset_query およびserver_reset_query_always 設定を確認します。デフォルトでは、pgBouncerはトランザクションプーリングでリセットクエリをスキップし、デフォルトのdiscard_all よりもConnection Managerのfast リセットモードに似ています。その動作と一致するようにserver_reset_mode からfast を設定するか、より安全で遅いデフォルトのためにdiscard_all のままにします。 リセットモードの構成 を参照してください。

  3. read_write_max_server_connections をpgBouncerのpool_size と同様の値に設定し、read_write_max_client_connections をpgBouncerのmax_client_conn と同様の値に設定します。最初に、 read_only_max_server_connections およびread_only_max_client_connections を同じ値に設定します。実際のワークロードに基づいて、4つの設定すべてを調整します。

  4. pgBouncerの代わりにConnection Managerの読み取り/書き込みポートを指すようにアプリケーションの接続文字列を更新します。

  5. アプリケーションの動作を確認します。

  • session モードでは、アプリケーションの動作は直接Postgres接続から変更ありません。

  • transaction モードでは、SET コマンド、プリペアドステートメント、またはWITH HOLD カーソルの使用に特に注意を払い、必要に応じて調整します。 Using connection pooling in your application を参照してください。

  1. 移行が確認されたら、インフラストラクチャからpgBouncerを削除します。

認証構成は、各PGDノードのpg_hba.conf に残ります。個別のユーザーリストまたはプーラー構成ファイルは必要ありません。接続マネージャーを介してPostgresに接続できるユーザーはプールを使用でき、アクセスを許可または取り消すための2番目の場所はありません。

接続マネージャーは、一部のシナリオでの直接Postgres接続と比較して、追加の制限を課します。移行を完了する前に、アプリケーションを徹底的にテストします。

目次