使用HAProxy和PGBouncer的PostgreSQL高可用性/可伸缩性

我有一个Web应用程序的多个PostgreSQL服务器。通常，一个主机和多个从机处于热备用模式（异步流复制）。

我使用PGBouncer进行连接池：在连接到本地主机上的数据库的每台PG服务器（端口6432）上安装了一个实例。我使用事务池模式。

为了在从属服务器上平衡只读连接的负载，我将HAProxy（v1.5）与conf差不多使用：

listen pgsql_pool 0.0.0.0:10001
        mode tcp
        option pgsql-check user ha
        balance roundrobin
        server master 10.0.0.1:6432 check backup
        server slave1 10.0.0.2:6432 check
        server slave2 10.0.0.3:6432 check
        server slave3 10.0.0.4:6432 check

因此，我的Web应用程序连接到haproxy（端口10001），该端口在每个PG从站上配置的多个pgbouncer上进行负载平衡连接。

这是我当前架构的表示图：

这样可以很好地工作，但是我意识到有些实现方式大不相同：Web应用程序连接到单个PGBouncer实例，该实例连接到HAproxy，后者在多个PG服务器上实现负载平衡：

最好的方法是什么？第一个（我当前的一个）还是第二个？一种解决方案比另一种解决方案有什么优势？

谢谢

您现有的HAProxy-> PGBouncer-> PGServer方法的配置更好。那只会起作用。原因如下：HAProxy将连接重定向到其他服务器。这导致数据库连接中的MAC地址更改。因此，如果PGBouncer高于HAProxy，则每次由于MAC地址更改而使池中的连接失效。

pgbouncer维护与postgres服务器在一个池中的连接。在大容量环境中，TCP连接建立时间很重要。

发出大量数据库请求的客户端将必须为每个请求与远程PGBouncer建立连接。这比在本地运行PgBouncer昂贵（因此应用程序在本地连接到pgbouncer），并且pgBouncer维护与远程PG服务器的连接池。

因此，IMO，PGBouncer-> HAProxy-> PGServer似乎比HAProxy-> PGBouncer-> PGServer更好，尤其是当PGBouncer在客户端应用程序本地时。

我不得不不同意多纳泰洛提供的答案。

您会看到，如果您的应用程序不使用本地池来管理数据库连接，则每次需要查询数据库时，它都会创建一个新的连接。使用PgBouncer时发生的情况完全相同，因此使用它会带来非常好的改善。

当PgBouncer通过池化PostgreSQL连接来管理PostgreSQL连接时，与直接向数据库打开连接相比，您的应用程序花费在打开连接上的时间大大减少。这是因为PG每次请求连接时检查和验证凭据以及所有内容的速度都很慢。

因此，方法App-> HAProxy-> [PgBouncer-> PostgreSQL]是更好的方法，因为PgBouncer节省了与PG的连接时间。同时考虑池化模式也很重要。您必须了解应用程序的行为方式。它主要是交易性的吗？还是更多地执行一堆具有高并发性的小型SQL语句？所有这些参数都会影响性能。