Pgpool-II 4.7.3 介绍与选型指南

目标：本篇是 Pgpool-II 的认知与选型第一站——基于官方渠道联网溯源（查询日期 2026-10-20），讲清它是什么、架构如何、有哪些能力边界，并与 PgBouncer、Odyssey、应用层读写分离做量化对比，帮助你在「连接池/读写分离/高可用中间件」这条技术路线上做出正确选型。本篇为纯溯源认知篇，所有数据均标注来源与查询日期；安装、配置、命令的逐步实测与真实回显见本专栏后续部署、配置、命令三篇。

一、环境信息

本篇为 A1 认知篇，按写作规范只做联网溯源、不做本地实测。溯源环境与来源清单如下：

💡 说明：Pgpool-II 的主开发仓库长期托管在项目自建 Git（pgpool.net），GitHub 上的 pgpool/pgpool2 是官方镜像仓库，星数（445）远低于其真实用户规模，横向对比星数时需注意这一背景，不要把「星数低」误读为「不活跃」。

二、软件概述

2.1 它是什么

Pgpool-II 是 PostgreSQL 官方生态中最老牌的数据库中间件：它工作在 PostgreSQL 服务器与 PostgreSQL 客户端之间，对应用表现为「一个 PostgreSQL」——应用用标准 PostgreSQL 协议（含扩展查询协议）连它，它再把连接复用、SQL 路由（读写分离/负载均衡）、故障切换、高可用（watchdog/VIP）、在线恢复、查询缓存等能力施加到后端的多台 PostgreSQL 上（来源：pgpool.net 官网首页定位描述，查询日期 2026-10-20）。

它的核心卖点可以概括为一句话：不改应用代码，把多台 PostgreSQL 变成一个带连接复用、自动读写分离和故障自愈的统一入口。

• 维护方：Pgpool-II Global Development Group（PostgreSQL 官方生态项目，与 PostgreSQL 主项目同源社区）。
• 实现语言：C；架构为多进程模型（每个客户端连接由一个独立子进程服务）。
• 许可证：BSD-3-Clause（GitHub 仓库 LICENSE 标识，查询日期 2026-10-20）。
• 部署形态：独立进程/服务（守护进程 pgpool），Debian/Ubuntu 走 apt.postgresql.org 仓库、RHEL/Rocky 走官方 Yum 仓库、亦提供源码包（官网 Downloads 页，查询日期 2026-10-20）。

2.2 版本与分支现状（2026-10-20 实查）

4.7.3 是一次安全修复版，两个 CVE 值得所有存量用户知晓（来源：Release 4.7.3 官方公告，查询日期 2026-10-20）：

• CVE-2026-92867：watchdog 故障切换消息处理存在漏洞，攻击者可发送畸形 failover 请求消息，向任意内存地址写入任意 32 位值（内存破坏）。影响 3.54.2 全系列及 4.3.04.3.20、4.4.04.4.17、4.5.04.5.12、4.6.04.6.7、4.7.04.7.2；官方强烈建议升级到 4.7.3（或对应系列的 4.6.8/4.5.13/4.4.18/4.3.21），临时缓解措施为关闭 watchdog（use_watchdog = off）或将 watchdog 访问限制在可信网络。
• CVE-2026-92868：客户端证书认证时未正确处理 X.509 证书 CN 字段中的 NUL 字节，恶意客户端可借此绕过密码、以另一用户身份连接。同类受影响版本区间，修复版本同上。

4.7 大版本（4.7.0，2025-12-23）的主要增强（来源：Release Notes A.4，查询日期 2026-10-20）：

• 退役 Slony 模式：backend_clustering_mode 不再支持 slony（Slony-I 上游 2022 年后无新版本，官方确认无活跃用户后移除）。
• 参数 logdir 更名为 work_dir。
• 支持前端/后端协议 3.2（对应 PostgreSQL 18 的新协议版本）。
• watchdog 与 heartbeat 接收端安全增强。
• pcp_proc_info 与 show pool_pools 新增客户端信息字段，并新增扩展函数 pgpool_adm_pcp_proc_info。
• 在线恢复数据库（online recovery database）可配置。
• 导入 PostgreSQL 18 的 SQL 解析器（SQL 解析能力对齐 PG18 语法）。

2.3 一句话人设

如果用类比：Pgpool-II 像是「PostgreSQL 世界里的 MySQL Proxy + Keepalived + MHA 的合体」——它同时做连接复用、SQL 层读写分离、故障切换与 VIP 漂移、备库在线重建；而 PgBouncer/Odyssey 是「纯连接池」，HA 与恢复要靠 Patroni 等外挂（Patroni、pgBackRest 等工具的实战见本平台 PostgreSQL 专栏，如 《PostgreSQL 18 流复制（Streaming Replication）集群部署指南》）。

三、核心架构

3.1 拓扑与进程模型

Pgpool-II 典型部署为「应用 → Pgpool-II → N 台 PostgreSQL」三层拓扑（文字示意，依据官方文档架构描述整理）：

                 ┌────────────┐
   应用客户端 ──▶ │ Pgpool-II  │ ──▶ PostgreSQL 节点0（主库，可写）
   (协议 9999)    │  多进程     │ ──▶ PostgreSQL 节点1（备库，只读，流复制）
                 └─────┬──────┘
                       │ PCP 9898（管理）、watchdog 9000（多 pgpool 互检）
                       ▼
              另一台 Pgpool-II（watchdog 对端，共用同一组后端）

进程模型为多进程：一个父进程（pgpool 主进程）负责 fork/监管，每个客户端连接分配一个独立子进程，另有 PCP 服务进程、watchdog/心跳进程、流复制检查（sr check）、健康检查（health check）与在线恢复 worker 等辅助进程。这与 PgBouncer 的「单进程事件驱动」和 Odyssey 的「多线程 worker」形成三种鲜明的架构流派。

💡 技术拓展：数据库连接池有三种「池化层级」，决定了空闲连接能否被另一个会话复用——

池化层级	原理	代表实现	适用场景
会话级（session）	客户端独占后端连接直至断开	Pgpool-II	连接数不爆炸、需要会话状态（临时表、SET）的场景
事务级（transaction）	事务结束后连接即归还池，供其他会话复用	PgBouncer、Odyssey	海量短连接、应用不支持会话保持语义时
语句级（statement）	每条语句执行完即归还连接	PgBouncer（pool_mode=statement）	极端高并发、且不使用多语句事务的场景

Pgpool-II 的池是「每个子进程按 数据库+用户 维度持有少量后端长连接复用」，属于会话级池化——它的价值在路由与 HA，而不是像 PgBouncer 那样用事务级复用把上万客户端压缩到几十个后端连接。本文对比中各产品的池化能力差异即由此展开。

3.2 运行模式：backend_clustering_mode

Pgpool-II 通过 backend_clustering_mode 参数声明后端集群形态（来源：官方文档 runtime-config-running-mode 与 Release Notes，查询日期 2026-10-20）：

关键解读：绝大多数生产形态是 streaming_replication 模式——数据复制交给 PostgreSQL 原生流复制，Pgpool-II 专注「路由 + 高可用 + 恢复」。内置复制（raw）模式只适合无法启用流复制的特殊场景，会把复制一致性责任转移到中间件层，不推荐作为常规选型。

3.3 关键子系统一览

依据官方文档功能划分，Pgpool-II 由以下子系统组成（每个子系统的参数级实测见 《Pgpool-II 4.7.3 配置参数详解》）：

1. 连接池（Connection Pool）：按「数据库+用户」维度复用后端连接，核心参数 num_init_children（子进程数）× max_pool（每进程池深）。
2. 负载均衡/读写分离（Load Balance）：语句级路由——SELECT 走备库（可配权重 backend_weight），写语句与显式事务内语句走主库；函数读取可用 white_function_list/black_function_list 精确控制。
3. 流复制检查（SR Check）：周期性确认主备角色与复制延迟，延迟超阈值可把读流量切回主库（sr_check_period 等）。
4. 健康检查（Health Check）：周期探测后端可达性，探活失败触发 failover。
5. watchdog 高可用：多台 pgpool 组成仲裁集群，通过心跳互检，在 Master pgpool 上挂载/漂移 VIP，pgpool 宕机或失联时 VIP 自动漂移到活节点（应用永远只连 VIP）。
6. 在线恢复（Online Recovery）：借助 pgpool_recovery 扩展 + pcp_recovery_node，在不停止主库的前提下用 rsync 等方式重建备库。
7. 内存查询缓存（In-memory Query Cache）：把 SELECT 结果按查询语句缓存到共享内存或 memcached，命中后直接返回（memqcache_method = shmem|memcached）。
8. PCP 管理接口：独立端口（默认 9898）+ pcp_* 命令族，实现节点上下线、主备切换、恢复、进程查看等运维操作（全套实测见《Pgpool-II 4.7.3 常用 CLI 命令与工具详解》）。

四、功能特性

4.1 连接池

按「数据库+用户」复用后端连接：客户端断开后，子进程保留后端连接供下一个同维度的客户端复用，省掉后端 fork/认证开销。num_init_children 限制前端并发上限，max_pool 控制每进程可缓存的不同「数据库+用户」连接数。它是会话级池化（见 3.1 技术拓展），不具备事务级压缩能力。

4.2 读写分离与负载均衡

• 语句级路由：默认 SELECT 类读语句按 backend_weight 权重分发到备库，写语句固定走主库。
• 显式事务内的语句默认不参与负载均衡（整事务走主库，保证一致性）；函数调用是否算「读」由 white_function_list/black_function_list 声明（来源：官方文档负载均衡章节要点，查询日期 2026-10-20）。
• 复制延迟保护：SR 检查发现备库延迟超过 delay_threshold 时，读流量自动回落主库，避免读到旧数据。

💡 技术拓展：读写分离的实现层面不止中间件一种，常见四类方案对比——

实现层面	代表	优点	缺点
中间件代理	Pgpool-II	应用零改造、能力全（含 HA/恢复）	多一跳转发、SQL 兼容性受协议解析限制
数据库驱动	pgjdbc targetServerType=preferSecondary、libpq target_session_attrs	无新增组件	每种语言/驱动能力不一，无统一故障切换
应用框架	Spring AbstractRoutingDataSource、ShardingSphere-JDBC 读写分离	灵活可控	侵入业务代码，自研自维护
数据库内置	只读副本 + 应用按端口分流（主备分端口暴露）	简单直接	故障切换与端口收敛需外挂

Pgpool-II 的差异化价值在「代理层一次解决路由+池化+HA+恢复」；如果只是简单分流、愿意改应用，驱动/框架方案更轻。本方案量化对比见第七章。

4.3 watchdog 高可用（HA）

Pgpool-II 自身是单点，watchdog 通过「多台 pgpool 互检 + VIP 漂移」消除这一单点：多台 pgpool 挂同一组后端，心跳超时判定对端失联，获得仲裁多数的一方在 Master 上用 ip addr add 挂载 VIP；pgpool 实例宕机时 VIP 秒级漂移，应用侧无感（来源：官方 watchdog 章节能力描述，查询日期 2026-10-20；4.7 对 watchdog 与心跳链路做了安全增强）。这也是 4.7.3 安全公告（CVE-2026-92867）聚焦 watchdog 消息处理的原因——它是暴露在网络里的高价值组件，务必升级到 4.7.3 并把 watchdog 端口限制在可信内网。

4.4 在线恢复

备库故障或数据落后时，pcp_recovery_node 触发在线重建：在主库安装 pgpool_recovery 扩展后，Pgpool-II 调用 rsync 系函数把主库数据同步到新备库并拉起流复制，全程主库不停服（4.7 起恢复所用数据库可配置）。这是相对「pg_basebackup + 手工重建」的显著运维增益。

4.5 内存查询缓存

SELECT 结果按查询语句哈希缓存于共享内存或 memcached（memqcache_method），表数据变更时自动失效对应缓存。适合读多写少、语句模式高度重复的场景；写频繁场景命中率低反而增加开销，需按业务实测取舍。

4.6 协议兼容与 SQL 解析

支持 PostgreSQL 前端/后端协议 v3，4.7 起支持 v3.2；内置 SQL 解析器（4.7 已对齐 PostgreSQL 18 语法）用于语句识别与路由。这既带来「应用不改代码」的透明性，也构成功能边界：协议解析覆盖不到的语句形态（部分扩展协议用法、COPY 细节、特殊函数等）可能无法正确路由或复制，官方文档设有 Limitations 专章，部署前应逐条核对（来源：官方文档目录与 Release Notes，查询日期 2026-10-20）。

五、快速开始（最小可用示例）

以下最小路径来自官方文档与官网下载页（溯源引用，查询日期 2026-10-20；本篇不做本地实测，逐步安装实测与真实回显见《Ubuntu 22.04 安装 Pgpool-II 4.7.3 指南》）：

1. 安装（Ubuntu 22.04 为例）：apt.postgresql.org（PGDG）仓库提供与官方同步的 pgpool2 包，官方 Downloads 页明确提供 Apt Repository 入口：

# PGDG 仓库配置后（完整步骤与实测回显见本专栏安装篇）：
apt-get install pgpool2        # 安装 pgpool 服务端与 pcp_* 工具
pgpool --version               # PGDG 源当前应给出 4.7.3 系列

2. 最小配置（/etc/pgpool2/pgpool.conf，参数名与取值依据官方文档示例）：

listen_addresses = '*'
port = 9999                      # 应用连 Pgpool-II 的端口
backend_hostname0 = 'pg1'        # 后端主库
backend_port0 = 5432
backend_weight0 = 0              # 主库读权重置 0，读流量全部走备库
backend_hostname1 = 'pg2'        # 后端备库
backend_port1 = 5432
backend_weight1 = 1
sr_check_period = 10             # 流复制状态周期检查
health_check_period = 10         # 后端健康检查，失败触发 failover
load_balance_mode = on

3. 启动与连接：

pgpool -n                        # 前台启动（systemd 部署则 systemctl start pgpool2）
psql -h <pgpool主机> -p 9999 -U postgres -d postgres   # 应用视角：就是一个 PostgreSQL

⚠️ 注意：后端需预置流复制主备（搭建过程见 《PostgreSQL 18 流复制（Streaming Replication）集群部署指南》）；pcp.conf、pool_hba.conf 两个配套文件需同步配置，缺一会导致 PCP 命令与前端认证失败。

六、适用场景与限制

6.1 适用场景

• 存量应用零改造上读写分离：应用只会连「一个 PostgreSQL」，Pgpool-II 在代理层完成主备路由与读负载均衡。
• 需要统一入口高可用：多 pgpool + watchdog VIP，主库故障时 failover 由 pgpool 触发（promote 备库），pgpool 自身故障由 VIP 漂移兜底。
• 备库运维自动化：备库坏掉后一条 pcp_recovery_node 在线重建，主库不停。
• 连接数可控的 OLTP + 报表混合负载：读流量按权重摊到备库，主库专心写。

6.2 限制与不适用（部署前必读）

• 海量连接压缩不是它的强项：会话级池化意味着「前端连接数 ≈ num_init_children 上限」，上万空闲长连接的场景应选事务级池化的 PgBouncer/Odyssey（或两者叠加：外层 PgBouncer + 内层 Pgpool-II 的组合也常见，但会引入两层协议代理）。
• SQL 兼容性受协议解析约束：官方文档 Limitations 专章列明复制/负载均衡模式下不保证的语句类型（显式事务内默认不 LB、函数读取需白名单声明、部分扩展协议与 COPY 场景受限等），上线前须逐条比对（来源：官方文档 Limitations，查询日期 2026-10-20）。
• 不做分库分表：跨库水平拆分请看 Citus/Vitess 一类方案（Citus 实战见 《PostgreSQL 18 Citus 分布式集群部署指南》）。
• watchdog 是安全要害：4.7.3 修复的 CVE-2026-92867 正是 watchdog 消息处理漏洞，任何版本上线都应把 watchdog/heartbeat 端口限制在可信网络并保持最新补丁版。
• 性能上多一跳：多进程逐连接转发的开销高于直连，也高于单进程事件驱动的 PgBouncer；对延迟极度敏感且只需池化的场景，PgBouncer 更轻。

七、同类选型对比（含量化维度）

7.1 量化总表（四方案横向）

数据来源与口径：版本与发布日期取自各官方站/官方新闻（查询日期 2026-10-20）；星数经 shields.io 徽章取证（2026-10-20）；架构与 License 取自各官方仓库/文档。

表内量化结论解读：三款 C 语言池化组件里，PgBouncer 星数最高（4.4k）且最轻量，Odyssey 次之（3.6k）主打多线程高并发，Pgpool-II 星数最低（445，含官方镜像仓库背景）但功能面最宽——它不是「更好的连接池」，而是「连接池之外的五件事（LB/HA/恢复/缓存/统一入口）」的提供者。选型时先问要不要这五件事，再比性能。

7.2 能力矩阵

关键差异解读：矩阵里只有第一行的「连接池」是三款代理共有的基本功；从「读写分离」往下，PgBouncer 全线缺席——它把每件多余的事都留给了外挂；Pgpool-II 全线在场但每一项都比专职工具「粗一点」；Odyssey 介于两者之间（池化强、路由有、HA 无）；应用层方案的能力完全由你选择的驱动/框架决定，且没有任何运维侧兜底。

7.3 「如果…则…」选型建议

• 如果应用连接数不大（几百以内）、想要读写分离 + 自动 failover + 备库在线重建且不能改应用代码 → Pgpool-II（streaming_replication 模式 + watchdog 双节点起步）。
• 如果只是海量短连接需要压缩后端连接数（上千到上万），不关心路由 → PgBouncer（事务级池化，最轻、最稳、社区最热）。
• 如果单实例要扛极高并发池化、需要多线程利用多核、Yandex 级大规模生产背书 → Odyssey。
• 如果团队能改代码、拓扑简单（一主一备）、愿意自己处理 failover → 应用层读写分离（驱动 target_session_attrs/框架路由），再配 Patroni 做 HA（Patroni/流复制实战见 《PostgreSQL 18 流复制（Streaming Replication）集群部署指南》）。
• 如果两者都要（海量连接 + 读写分离）→ 组合方案：应用 → PgBouncer → Pgpool-II → PG 主备（注意两层代理的延迟与排障成本），或应用 → Pgpool-II（调大 num_init_children）视连接压力取舍。
• 无论选谁：升级到各产品最新安全版（Pgpool-II ≥4.7.3、PgBouncer ≥1.25.2），三款产品 2026 年都有已修复的 CVE（见表 7.1）。

7.4 社区活跃度小结（量化口径）

• 版本节奏：Pgpool-II 在 2025-12-23（4.7.0）、2026-06-04（4.7.2 等 5 分支同步）、2026-09-29（4.7.3 等 5 分支同步）保持季度级发布，且每次补丁 5 个分支同步走，维护纪律性极强（来源：官网 News 与 Release Notes，查询日期 2026-10-20）。
• 星数口径：PgBouncer 4.4k > Odyssey 3.6k > Pgpool-II 445（shields.io，2026-10-20）；再次强调 Pgpool-II 主仓库不在 GitHub，星数不代表活跃度，其 Release Notes 中持续出现的核心维护者（Tatsuo Ishii 等）与 5 分支并行维护是更可靠的活跃度证据。
• 生态：Pgpool-II 深度绑定 PostgreSQL 官方生态（apt.postgresql.org/pgpool.net Yum 仓库官方发包、文档与 PG 主版本同步更新、4.7.3 已内置 PG18 SQL 解析器）；PgBouncer 由 PostgreSQL 官网发布新闻；Odyssey 由 Yandex 维护并同步发布到 postgresql.org 新闻（各来源查询日期均为 2026-10-20）。

八、参考链接

1. Pgpool-II 官网：https://www.pgpool.net/
2. Pgpool-II 4.7.3 官方文档：https://www.pgpool.net/docs/latest/en/html/index.html
3. Release 4.7.3（CVE-2026-92867 / CVE-2026-92868 公告）：https://www.pgpool.net/docs/latest/en/html/release-4-7-3.html
4. Release 4.7.0（4.7 新特性）：https://www.pgpool.net/docs/latest/en/html/release-4-7-0.html
5. 官网下载页（Yum/RPM/Apt/Source）：https://www.pgpool.net/mediawiki/index.php/Downloads
6. GitHub 镜像仓库：https://github.com/pgpool/pgpool2
7. PgBouncer 官网与变更日志：https://www.pgbouncer.org/ 、 https://www.pgbouncer.org/changelog
8. Odyssey 1.5.1 发布新闻（postgresql.org）：https://www.postgresql.org/about/news/odyssey-151-released-3348/
9. 第三方选型参考《Top 4 Open Source Postgres Connection Poolers (2026)》（Bytebase）：https://www.bytebase.com/blog/open-source-postgres-connection-pooler/
10. 站内相关：《PostgreSQL 18.6 介绍与选型指南》、《PostgreSQL 18 流复制（Streaming Replication）集群部署指南》
11. 本专栏后续篇章：《Ubuntu 22.04 安装 Pgpool-II 4.7.3 指南》、《Pgpool-II 4.7.3 配置参数详解》、《Pgpool-II 4.7.3 常用 CLI 命令与工具详解》