Using connection pooling in your application#

Connection Manager Authentication の接続プーリングで動作するようにアプリケーションを調整します。

プーリングの有効化と操作に関するDBAガイダンスについては、 Configuring connection pooling を参照してください。

アクティブプールモードの理解#

bdr.node_group_summary を照会して、アクティブなプールモードを確認します。

SELECT node_group_name, server_pool_mode FROM bdr.node_group_summary;

プールモードは、トランザクション間でどのセッション状態を持続するかを決定します。

Feature

none/session

transaction

SET changes persist

Yes

No

PREPARE/EXECUTE statements persist

Yes

No

Temporary tables persist

Yes

No

Advisory locks across transactions

Yes

No

Holdable cursors (WITH HOLD)

Yes

No

LISTEN subscriptions

Yes

No

none およびsession モードでは、アプリケーションは、ほとんどの場合Postgres直接接続の場合と同じように動作します。例外は、接続マネージャーが特定の接続パラメーターのセットのみをバックエンドに転送することです。詳細は、 セッションパラメーターの管理 を参照してください。 none とsession の違いはインフラレベルです。session モードでは、クライアントが切断した後にバックエンド接続が再利用され、サーバーオーバーヘッドが削減されますが、これはアプリケーションには見えません。

transaction モードでは、各トランザクションが終了し、ほとんどのセッション状態がクリアされると、バックエンド接続はプールに返されます。次のトランザクションは別のバックエンドで実行できます。一部のPostgres機能は、トランザクション間で持続せず、結果として動作しないセッション状態に依存しています。完全なリストについては、 Connection pooling's unsupported features を参照してください。

アプリケーションがこれらの機能に依存している場合は、 DBAに session またはnone モード Configuring connection pooling を参照してください 、または影響を受けるコードパスを再設計して、単一のトランザクション内のすべての状態を維持します。

アプリケーションをトランザクションモードに適応させる#

Postgresの直接接続で動作する一部のアプリケーションパターンは、トランザクションモードでの調整が必要です。

セッションパラメーターの管理#

接続マネージャーは、特定の接続パラメーターのセットをバックエンドに転送し、トランザクションモードでの新しいバックエンドの割り当てごとにそれらを再適用します。認識するパラメーターはclient_encoding 、DateStyle 、TimeZone 、standard_conforming_strings 、application_name 、search_path 、およびextra_float_digits です。

これらをSET コマンドではなく接続文字列で設定して、プールが割り当てるすべてのバックエンドに適用されるようにします。

host=myhost dbname=mydb options=-c search_path=myschema -c work_mem=256MB

またはURIで。

postgresql://myhost/mydb?options=-c%20search_path%3Dmyschema%20-c%20work_mem%3D256MB

認識されるリストの外部のパラメーターは、 options 接続パラメーターを介して渡されない限り、バックエンドの変更に再適用されません。

プリペアドステートメントを使用する#

接続マネージャーは、バックエンドで欠落しているプリペアドステートメントを自動的に検出し、オンデマンドで再準備するため、拡張クエリプロトコルを介して送信されるプリペアドステートメントは、トランザクション間でシームレスに動作します。ほとんどのクライアントライブラリは、デフォルトで拡張クエリプロトコルを使用します。

DISCARD ALL は、各トランザクションの最後にバックエンド接続がプールに返されたときに実行され、PREPARE /EXECUTE SQLステートメントで作成されたプリペアドステートメントの割り当てを解除します。これらのエラーを回避するには、次のプラクティスに従ってください。

  • PREPARE 、EXECUTE 、およびDEALLOCATE SQLステートメントは避けます。代わりに拡張クエリープロトコルを使用します。ほとんどのクライアントライブラリはデフォルトで使用します。

  • PREPARE /EXECUTE /DEALLOCATE SQLステートメントを使用する必要がある場合は、使用するトランザクション内で発行します。