PostgreSQL/Pgpool-II/プロセス構造

PostgreSQL/Pgpool-II

プロセス構造 †

Pgpool †

• pgpoolのメインプロセスであり、子プロセスの親。
• メインプロセスは、イベント通信用のパイプやシグナルの設定などを行ない、WatchDog、Child、PCP、Workerプロセスをforkした後はループに入る。
• ループでは、ヘルスチェックの設定がされていれば行ない、タイムアウト設定付きでselectシステムコールを使ってイベントディスクリプタを監視する。
• Pgool-IIの親プロセスは、socket、bind、listenはするが、acceptするのは子プロセスである（PostgreSQLでは、postmasterプロセスがacceptする）。したがって、Pgpoolでは、Pgpoolの親プロセスが死んでも子プロセスは接続を受けることができる。

Child †

• num_init_childerの数だけプロセスがpre_forkされ、クライアントからの接続を処理する。子プロセスの待ち受けにはselectシステムコールが使われ、どの子プロセスが処理を受けるかはシステムにより選択される。serialize_acceptパラメータを有効にすると、pgpoolは受け付けるクライアント接続のシリアライズを有効にする（Thundering Herd Problemへの対処）。これはセマフォを使って行われている。
   参考  wait_for_new_connections() - on https://github.com/pgpool/pgpool2/
• 接続要求を受けると、各バックエンドに接続し、クエリを処理するループに入る。 クライアントが接続を閉じると、クエリループを終了しセッションを終了する。
• 最大接続数を超えるクライアント接続があった場合、クライアントは待たされる（カーネルのlistenキューサイズに依存し、このサイズはPgpool-IIの設定パラメータで調整可能である）。
  参考https://lets.postgresql.jp/documents/technical/pgpool-II-tcp-tuning/1
• データベースに障害が起きた場合、指定したデータベースを負荷分散先に指定している子プロセスは再起動され、クライアントのセッションは切れる。
• コネクションプーリングでは、max_pool分のバックエンド接続がキャッシュされ再利用される。プールのバックエンド接続は「 データベース名：ユーザー名」のペアで識別される。max_poolを超えるペアでのバックエンド接続があった場合、最も古い接続が破棄される。
• child_max_connectionsが0より大きい場合、接続回数が指定された値以上となると子プロセスは再起動される。これは、主にバックエンドが使う資源の肥大化防止のために用意されているパラメータである。

PCP †

• unixドメインソケットとPCPの待ち受けアドレス:ポートでソケットを作成し、selectシステムコールでディスクリプタを監視する。
• selectから戻るとacceptを実行し、コマンド実行のために新しくプロセスをforkする。以降は、forkされたworkerがコマンド処理を実行する。
   参考  pcp_worker_main() - on https://github.com/pgpool/pgpool2

Worker †

• マスタースレーブモードでストリーミングレプリケーションで動作している時、プライマリとスレーブノード間でのレプリケーション遅延を監視する。この設定はsr_check_periodで0より大きな値が設定されていると有効となる。sr_check_periodごとにバックエンドと接続し、WALのLSN(Log Sequence Number)をチェックする。
   参考  do_worker_child() - on https://github.com/pgpool/pgpool2

WatchDog †

LifeCheck †

heartbeat sender †

heartbeat receiver †