LASSIC Media らしくメディア
Pgpool-IIとは？冗長化と負荷分散の仕組みと導入を解説
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- Pgpool-IIはアプリケーションとPostgreSQLの間に入り、故障時の切り替えと読み込みの振り分けを受け持つ無料のソフトです。
- Pacemakerはデータベース以外のソフトも含めて切り替えを管理する仕組みで、受け持つ仕事が違います。
- 導入では複製の方式とPgpool-IIの台数を先に決め、故障を実際に起こして切り替わりを確かめることが大切です。
※ 本記事は2026年11月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
データベースのサーバーが1台止まっただけで、業務システム全体が使えなくなった。参照の多い画面が遅いのに、サーバーを増やしても負荷が分かれない——。PostgreSQLを1台で動かしているシステムでは、こうした悩みが起こりがちです。Pgpool-II（ピージープール・ツー）は、アプリケーションとPostgreSQLの間に入り、複数のPostgreSQLサーバーを1つのデータベースのように見せるオープンソースのミドルウェア（アプリケーションとデータベースの仲立ちをするソフト）です。
故障したサーバーを自動で切り離したり、読み込みを複数のサーバーに振り分けたりできます。ただし万能ではなく、Pgpool-II自体の冗長化も考える必要があります。本記事では、情報システムの担当者に向けて、Pgpool-IIの仕組み、Pacemakerとの違い、導入の進め方、そして外部に頼むときに確認したい点を整理します。
Pgpool-IIとは
PostgreSQLの公式ドキュメントによると、主サーバーの故障を見つけて待機側に知らせる仕組みは、PostgreSQL自体には含まれていません。*6 Pgpool-IIはこの役割を担う道具の一つで、公式の文書は主な機能を次のように挙げています。*1
- 自動フェイルオーバー：故障したサーバーを自動で取り除き、データベースの処理を続ける
- 負荷分散：読み込みの問い合わせを複数のサーバーに振り分ける
- コネクションプーリング：一度つないだ接続を残しておき、同じ条件の接続に使い回す
- Watchdog：Pgpool-IIを複数台で動かし、1台が止まっても待機側が引き継ぐ
アプリケーションからはPgpool-IIがPostgreSQLサーバーに見えるため、既存のアプリケーションはほとんど手を加えずに使えます。*2 ライセンスはBSDやMITに近い条件です。冗長化の考え方は冗長化とはで扱っています。
冗長化と負荷分散の仕組み
Pgpool-IIは、PostgreSQLのレプリケーション（データを別のサーバーに複製する機能）と組み合わせて使います。書き込みを受ける1台をプライマリ、複製を持って待機する側をスタンバイと呼びます。*5
- 書き込み（登録・更新・削除）は、プライマリにだけ送る
- 読み込みは、プライマリとスタンバイに振り分ける
- 1つのトランザクション（ひとまとまりの処理）で書き込んだ後の読み込みは、振り分けずにプライマリへ送る*4
- プライマリが故障したら、スタンバイを新しいプライマリに切り替えて処理を続ける
注意したいのは複製のタイミングです。書き込みの完了を全サーバーで待つ同期型なら、切り替えでデータを失いません。遅れを許す非同期型では、切り替えで一部の処理が失われたり、少し古い結果が返ったりすることがあります。ただし同期型は、遅いネットワークでは性能が半分以下に落ちることもあります。*5 業務がデータの遅れをどこまで許せるかで選びます。
Pacemakerとの違い
PostgreSQLの冗長化では、Pgpool-IIのほかにPacemakerも候補に挙がります。Pacemakerは、オープンソースの高可用性クラスタのリソースマネージャー（サーバー上のソフトの起動・停止・切り替えを管理する仕組み）です。*7 両者は受け持つ仕事が違います。
| 項目 | Pgpool-II | Pacemaker |
|---|---|---|
| 位置づけ | アプリケーションとPostgreSQLの間に入るミドルウェア | 複数のサーバーの上でソフトの稼働を管理するクラスタの仕組み |
| 扱う対象 | PostgreSQLに特化 | PostgreSQLに限らず、さまざまなアプリケーションの冗長構成 |
| 主な機能 | 自動フェイルオーバー、読み込みの負荷分散、接続の使い回し | 故障の検知と復旧、起動と停止の順序の制御、主と従の2つの役割の管理 |
| 自身の冗長化 | Watchdogで3台以上を協調させる | クォーラム（多数決）を失ったときの動き方を設定できる |
| 入手の方法 | 公式サイトで配布 | 多くのLinuxディストリビューションに含まれる |
読み込みの振り分けまで済ませたいならPgpool-II、データベース以外のソフトもまとめて切り替えたいならPacemaker、と考えると整理しやすくなります。
導入の進め方
Pgpool-IIの導入は、ソフトを入れる作業よりも構成と切り替え方を決める作業が中心です。次の4つの段階で進めます。
- ステップ1：いまの状況を確かめる（読み込みと書き込みの比率、同時に接続する数、PostgreSQLの版）
- ステップ2：構成を決める（PostgreSQLの台数、同期型か非同期型か、Pgpool-IIを何台で動かすか）
- ステップ3：試験する（サーバーを止めて切り替わるか、アプリケーションが接続し直せるか）
- ステップ4：運用を決める（監視、版の更新、故障したサーバーを戻す手順）
ステップ2では、配下のPostgreSQLのメジャーバージョン（大きな版の番号）、OS、ハードウェアの種類をそろえる必要があります。*1 また、スプリットブレイン（2台が同時に主として動く状態）を防ぐには、少なくとも3台のPgpool-IIが必要です。*1
ステップ3では、プライマリを止める、ネットワークを切るといった故障を実際に起こして確かめます。PostgreSQLの版の更新と時期が重なる場合は、PostgreSQL 13のサポート終了と移行もあわせてご覧ください。
外部に頼むときに確認しておきたい点
Pgpool-IIはライセンス費用がかからない一方、設計と試験、その後の更新は自社で受け持つことになります。2026年9月29日にも、セキュリティの修正を含む新しい版が公開されました。*8 構築や運用を外部に頼むときは、次の点を見積もりの前に確かめておきます。
- どこまで頼むか：構成の設計、構築、切り替えの試験、運用の手順書のうち、どれを任せるか
- 切り替えの試験：どの故障を起こして何を確かめるか。結果を文書で受け取れるか
- 複製の方式：同期型と非同期型のどちらを選ぶか。その理由を説明してもらえるか
- 負荷分散の効果：読み込みと書き込みの比率を見たうえで、振り分けの効果を見積もっているか
- 運用後の更新：Pgpool-IIとPostgreSQLの版の更新を、誰がいつ行うか
特に負荷分散は、1つのトランザクションの中で書き込みの後に読み込みをする処理では効かず、その読み込みもプライマリに集まります。*4 導入の目的が冗長化なのか読み込みの性能なのかを、最初に伝えておきます。
まとめ：Pgpool-IIで確かめたい3つの点
Pgpool-IIでPostgreSQLを冗長化するうえで、確かめておきたい点は3つに整理できます。第一に、導入の目的が故障時の切り替えなのか、読み込みの振り分けなのかをはっきりさせること。第二に、同期型と非同期型のどちらで複製するかと、Pgpool-IIを何台で動かすかを構成の段階で決めること。第三に、プライマリを止めるなどの故障を実際に起こし、切り替わりとアプリケーションの再接続を確かめることです。この3点を踏まえておけば、「冗長化したはずなのに、いざ故障すると切り替わらなかった」という事態を避けやすくなります。迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
Pgpool-IIはWindowsのサーバーで動きますか
動きません。公式の文書は、Linuxをはじめ、SolarisやFreeBSDなどのほとんどのUNIX環境で動作し、Windowsでは動かないと説明しています。*1 構成を考えるときは、Pgpool-IIを置くサーバーのOSもあわせて決めておきます。
アプリケーションの改修は必要ですか
多くの場合、大きな改修は要りません。アプリケーションからはPgpool-IIがPostgreSQLサーバーに見えるため、接続先をPgpool-IIに変えて使います。*2 ただし、トランザクションの書き方によっては読み込みが振り分けられないため、試験の段階で確かめておきます。
マイナーバージョンが違うPostgreSQLを混ぜてもよいですか
マイナーバージョン（小さな版の番号）の違いは、大抵の場合問題にならないとされています。*1 ただし公式の文書は、すべての組み合わせを検証したわけではないとして、できればそろえておくことを勧めています。更新の手順を決めるときは、配下のサーバーの版をそろえる順番も決めておきます。
PostgreSQLの冗長化のご相談
Pgpool-IIによるPostgreSQLの冗長化と負荷分散の設計から、切り替えの試験、運用後の版の更新まで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：The Pgpool Global Development Group「Pgpool-II 4.7.3 文書：Pgpool-II とは？」（https://www.pgpool.net/docs/latest/ja/html/intro-whatis.html）。出典：自動フェイルオーバ・負荷分散・コネクションプーリング・Watchdogの説明、スプリットブレイン防止に3台以上が必要なこと、動作環境（Windowsでは動かない）、PostgreSQLのメジャーバージョン等をそろえる必要とマイナーバージョンの扱いの記述を参照（2026年11月確認）
- *2 参考：The Pgpool Global Development Group「Pgpool-II」公式サイト Introduction（https://www.pgpool.net/about/）。出典：既存アプリケーションをほとんど変更せずに使えること、BSDやMITに近いライセンスで配布されていることの記述を参照（2026年11月確認）
- *3 参考：The Pgpool Global Development Group「Pgpool-II 4.7.3 文書：4.1 Watchdog はじめに」（https://www.pgpool.net/docs/latest/ja/html/tutorial-watchdog-intro.html）。出典：Watchdogの役割、クォーラムのためにPgpool-IIノードを3以上の奇数にする記述を参照（2026年11月確認）
- *4 参考：The Pgpool Global Development Group「Pgpool-II 4.7.3 文書：5.8 負荷分散」（https://www.pgpool.net/docs/latest/ja/html/runtime-config-load-balancing.html）。出典：更新を伴うクエリをプライマリノードに送ること、トランザクション内で更新を伴うクエリの後は負荷分散されないことの記述を参照（2026年11月確認）
- *5 参考：The PostgreSQL Global Development Group「PostgreSQL Documentation Chapter 26. High Availability, Load Balancing, and Replication」（https://www.postgresql.org/docs/current/high-availability.html）。出典：プライマリ・スタンバイ・ホットスタンバイの説明、同期型と非同期型の違い、遅いネットワークでは同期型の性能が半分以下になり得ることの記述を参照（2026年11月確認）
- *6 参考：The PostgreSQL Global Development Group「PostgreSQL Documentation 26.3. Failover」（https://www.postgresql.org/docs/current/warm-standby-failover.html）。出典：プライマリの故障を検知してスタンバイに知らせる仕組みをPostgreSQLは提供していないことの記述を参照（2026年11月確認）
- *7 参考：ClusterLabs「Pacemaker」（https://clusterlabs.org/projects/pacemaker/）。出典：オープンソースの高可用性クラスタのリソースマネージャーであること、故障の検知と復旧、起動と停止の順序、主と従の役割、クォーラム喪失時の方針、主要なLinuxディストリビューションへの同梱の記述を参照（2026年11月確認）
- *8 参考：The Pgpool Global Development Group「Pgpool-II」公式サイト トップページ（Latest News）（https://www.pgpool.net/mediawiki/index.php/Main_Page）。出典：2026年9月29日にセキュリティ修正を含むPgpool-II 4.7.3ほかが公開された記述を参照（2026年11月確認）
