PostgreSQL接続プーリング：パート3 – Pgpool-II

このシリーズの以前の投稿では、接続プールのケースについて説明し、PgBouncerを紹介しました。この投稿では、最も人気のある代替手段であるPgpool-IIについて説明します。

Pgpool-IIは、PostgreSQLミドルウェアのスイスアーミーナイフです。高可用性をサポートし、自動負荷分散を提供し、マスターとスレーブ間で負荷を分散するインテリジェンスを備えているため、書き込み負荷は常にマスターに向けられ、読み取り負荷はスレーブに向けられます。 Pgpool-IIは、論理レプリケーションも提供します。 PostgreSQLサーバー側で組み込みのレプリケーションオプションが改善されたため、その使用と重要性は低下しましたが、これは古いバージョンのPostgreSQLにとって依然として価値のあるオプションです。これらすべてに加えて、接続プールも提供します！

一目で
Pgpool-IIの設定 次の手順に従って、Pgpool-IIをセットアップし、必要な接続プールサービスを有効にして、PostgreSQLサーバーに接続します。今すぐ読む 仕組み すべての機能をサポートするPgpool-IIアーキテクチャを確認し、接続プールがどのように機能するかを学びます。今すぐ読む Pgpool-IIは何をしませんか？ Pgpool-IIの制限を確認して、アプリケーションに適した接続プールかどうかを確認します。今すぐ読む

Pgpool-IIのセットアップ

Pgpool-IIバイナリは、Pgpool-IIのリポジトリを通じて配布されます。インストールの詳細については、このヘルプドキュメントをご覧ください。インストールしたら、必要なサービスを有効にするようにPgpool-IIを構成し、PostgreSQLサーバーに接続する必要があります。詳細については、こちらをご覧ください。

最小限のプーリング設定を行うには、次の情報を提供する必要があります。

• Pgpool-IIに接続するユーザーのユーザー名とmd5暗号化パスワード–これは、pg_md5utilを使用して簡単に生成できる別のファイルで定義する必要があります。
• 着信接続をリッスンするインターフェイス/IPアドレスとポート番号–これは構成ファイルで定義する必要があります。
• バックエンドサーバーのホスト名[複数のサーバーは、レプリケーションや負荷分散を使用する場合にのみ指定されます]。
• 有効にしたいサービス。デフォルトでは、接続プールはオンになっており、バイナリとともにインストールされた構成ファイルでは他のサービスはオフになっています。

これで完了です。準備は完了です。 Pgpool-IIで利用可能な構成は一見するともっと気が遠くなるかもしれませんが、Pgpool-IIの背後にいる人々は、私たちにとって本当に簡単になりました！

仕組み

Pgpool-IIは、すべての機能をサポートするために、PgBouncerよりも複雑なアーキテクチャを備えています。ただし、このセクションでは、接続プールがどのように機能するかを説明することに限定します。

Pgpool-II親プロセスはデフォルトで32個の子プロセスをフォークします–これらは接続に使用できます。アーキテクチャはPostgreSQLサーバーに似ています。1つのプロセス=1つの接続です。また、管理タスクに使用される「pcpプロセス」をフォークし、この投稿の範囲を超えています。これで、32人の子供が接続を受け入れる準備ができました。 PgBouncerと同様に、これらもPostgreSQLサーバーをエミュレートします。クライアントは通常のPostgreSQLサーバーとまったく同じ接続文字列で接続できます。

カーネルは、リスナーとして登録されている子プロセスの1つに着信接続を転送します。メインのPgpool-IIプロセスもエンドユーザーも、着信要求に応答する子プロセスを制御することはできません。アイドル状態の子供なら誰でもリクエストを受け取ることができます。アイドル状態の子が見つからない場合、接続要求はカーネル側でキューに入れられます– これにより、pgbenchなどのアプリケーションがハングし、クライアント接続を待機する可能性があります。

アイドル状態のPgpool-IIの子が接続要求を受信すると、次のようになります。

1. パスワードファイルでユーザー名を確認します。見つからない場合は、接続を拒否します。
2. ユーザー名が見つかった場合、提供されたパスワードをこのファイルに保存されているmd5ハッシュと照合します。
3. 認証が成功すると、このデータベースとユーザーの組み合わせに対してキャッシュされた接続がすでにあるかどうかがチェックされます。
4. ある場合は、クライアントへの接続を返します。そうでない場合は、新しい接続が開きます。
5. すべてのリクエストとレスポンスは、クライアントが切断されるのを待つ間、Pgpool-IIを通過します。
6. クライアントが切断されると、Pgpool-IIは接続をキャッシュするかどうかを決定する必要があります：
   • 空のスロットがある場合は、キャッシュします。
   • 空のスロットがない場合（つまり、この接続をキャッシュすると、許可されているmax_pool_sizeを超える場合）、内部アルゴリズムに基づいて決定されます。
7. 接続をキャッシュすることを決定した場合は、事前設定されたリセットクエリを実行して、すべてのセッションの詳細をクリーンアップし、別のクライアントで安全に再利用できるようにします。
8. これで、子プロセスはより多くの接続を自由に取得できるようになります。

Pgpool-IIは何をしませんか？

残念ながら、接続プールのみに焦点を当てている場合、特に少数のクライアントの場合、Pgpool-IIがうまく機能しないのは接続プールです。各子プロセスには独自のプールがあり、どのクライアントがどの子プロセスに接続するかを制御する方法がないため、接続の再利用に関しては運が悪すぎます。

ご覧のとおり、PgpoolとPgBouncerの長所はかなり異なります。シリーズの最後の投稿では、直接テストを行います。 、機能比較！しばらくお待ちください！