PostgreSQL高可用+负载均衡+连接池方案选型咨询

1. repmgr是否已覆盖高可用需求？ #

repmgr能覆盖集群节点管理、自动故障转移、主从切换这类核心高可用底层能力——比如主节点故障时自动选举新主，同步集群状态，管理节点的添加、移除和流复制监控。但它不负责应用层的流量路由、负载均衡、连接池管理，所以单靠repmgr只能解决“节点不宕机”的问题，无法处理流量分发和连接复用，不算完全覆盖生产级高可用的全链路需求。

2. repmgr与pgpool兼容性不佳是否属实？ #

并非绝对的兼容性差，而是两者的主节点状态检测逻辑存在天然冲突：repmgr自行维护集群主从状态，pgpool也有独立的节点健康检测和主节点判定机制，如果不做配置适配，可能出现两边对主节点的认知不一致，导致故障切换后pgpool未及时更新路由规则。但只要做好配置协同——比如让pgpool通过repmgr的状态文件或API获取集群状态，禁用pgpool自身的主节点检测，就能稳定协同工作，不少生产环境都在这么部署。

3. PgBouncer仅支持连接池不具备负载均衡能力吗？ #

PgBouncer的核心定位是连接复用与连接数管控，本身没有内置的读写分离、基于节点负载的路由或负载均衡功能。但可以通过自定义脚本、repmgr事件触发等方式实现简单的负载均衡逻辑——比如将只读流量导向不同从节点，或在主从切换时更新PgBouncer的路由配置。不过这种方式属于扩展能力，不如pgpool的原生负载均衡成熟，不是PgBouncer的核心卖点。

4. 该场景下推荐选用repmgr+pgpool还是repmgr+PgBouncer？ #

分场景决策：

• 若核心需求是完整的读写分离、节点负载均衡、故障后流量自动切换，选repmgr+pgpool。pgpool原生支持读写路由、负载分发，配合repmgr做好状态同步后，能形成一套覆盖节点高可用到流量管控的完整方案，适合存在大量只读查询的业务场景。
• 若核心需求是极致的连接池性能，读写分离需求弱或已有上层路由逻辑，选repmgr+PgBouncer。PgBouncer的连接池效率更高、资源占用更低，适合连接数压力大，但不需要复杂负载均衡的场景——比如应用层已经实现了读写分离，仅需统一管控数据库连接。

内容的提问来源于stack exchange，提问作者Xonos