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


17

我有一个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上进行负载平衡连接。

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

haproxy> pgbouncer> PostgreSQL

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

pgbouncer> haproxy> PostgreSQL的

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

谢谢

Answers:


10

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


7

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

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

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


1

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

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

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

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

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.