开头还是介绍一下群,如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis 等有问题,有需求都可以加群群内有各大数据库行业大咖,CTO,可以解决你的问题。
最近得到与PGBOUNCER的一个问题,问题大体上是这样描述的,一台POSTGRESQL的服务器,2000个max connection ,同时安装了4个 pgbouncer 在不同的机器上,来连接POSTGRESQL 数据库,最近出现了问题,连接数据库服务器超时的问题。
当被问及这个问题的时候,我其实也是比较惊讶,很少有听说这样使用的方式。一般PGBOUNCER 是安装在数据库上的,也就是与数据库成为一体的模式来进行使用的。为什么使用PGBOUNCER 主要的原因在于基于PG的原理,PG 更愿意去使用通过更少的连接数,来服务与更多的使用者,所以PGBOUNCER 实际上是一个 分时复用的核心概念的产品,也就是对于连接进行分时复用,所以这里PGBOUNCER 的功能是十分的简单,好处也有安装方便并且基本上比较稳定。
同时基于PGBOUNCER 的配置,也比较简单和简洁。配置主要分为几个部分
1 pgbouncer 配置文件内容
2 pgbouncer 的内部界面与使用
3 监控与配置刷新与使用
这里简单的说说pgbouncer 的配置文件的内容部分,配置的大块主要由databases , users , pgboucner 几个部分组成
1 databases 部分主要,主要以连接为主,pgboucner的连接主要包括连接符号,主机地址 端口号 数据库名字 以及连接中的测试query部分,database 这部分实际上是dbname = connection string ,来进行PG数据库与pgbouncer 之间进行对接的在PGBOUNCER 中显示的数据库。所以这个名字很可能与实际的你的物理数据库的数据库名字不一样,或者一个PGBOUNCER 可以连接多个物理的数据库,通过PGBOUNCER 作为一个数据安全的连接的屏蔽器使用。
这里有一个问题,经常被问题,就是如何登陆到PGBOUNCER 的界面中,这里很简单,你在登陆的时候,需要设置几个点
1 admin users 需要进行设置,这里的设置的账号就是登陆pgbouncer的账号名字,密码不用设置
2 登陆的时候,需要指定登陆的数据库是 pgbouncer 而不是别的,
3 在userlist.txt中设置 匹配admin users 的账号和密码,不要和登录数据库的账号重了。
做完这三点,那么就就可以登陆到pgbouncer 的系统中。
这部分在很多的文字中都模模糊糊,写的不清晰。为什么非要登陆到pgbouncer 中,主要的原因是,因为配置更改后,要动态加载到内存中,reload命令需要在内部进行运行。
下面这个例子是通过pgbouncer 连接到 192.168.198.100 的数据库中的数据库postgres的连接的例子,这样设置后就可以通过databases 模块与我们的数据库相连接。
pgbouncer
[databases]
postgres = host=192.168.198.100 port=5432 dbname=postgres connect_query='select 1'
[users]
[pgbouncer]
主要的PGBOUNCER 对于postgresql有利的部分就是 pool mode
在pool mode中重要的部分就是客户与服务器的连接模式的部分
1 session
2 transaction
3 statement
这三种的应用模式,中熟悉连接模式的同学都知道 transaction的模式是最常用的,而 session 的模式是最安全和妥当的,statement 没有什么应用去选择。实际上可以选择的部分只有两个 transaction and session.而在之前的测试中 session 本身的提高连接复用的可能性不高,同时程序的连接池也具有这个功能,所以,一般来说transaction 是 pgbouncer的最适合的应用模式。
实际上部署PGBOUNCER 有一个问题所在,就是如何进行HA, 也就是说PGBOUNCER 本身是和数据库一起绑定部署,还是分离部署的方式。
这点对于PGBOUNCER是一个部署的决定。实际上这个与本身的数据库的数量和部署的有关。
1 如果你的项目中的数据库很多,那么分离的部署方式是适合你的,这样有利于扩展数据库,和扩展连接代理。
2 部署多个 pgbouncer 同时通过应用的DNS 的轮训方式来进行高可用的切换放方式,而这样的方式的问题点,在于如果你的PGBOUNCER失败后,如何进行拉起的问题,或者通过DNS 来屏蔽出现故障的节点的部分。
3 通过K8S 来进行大量的pgbouncer 的部署,通过批量部署和借用 K8S 的管理功能更来将pgbouncer 高可用的工作进行接管。
4 直接将pgbouncer 与应用程序端进行绑定,也就是一个应用程序端一个pgbouncer 如果应用程序端失效或pgbouncer失效会很快被发现通过自动拉起的监控来进行pgbouncer的高可用设计。
PGBOUNCER本身承接了连接池维持的工作,如果pgbouncer断掉会影响现有的连接,所以应用程序必须有相关的功能针对PGBOUNCER失败后的重连机制和相关的工作机制。
PGBOUNCER 本身并不是DBA 自己的事情,是一个综合需要考虑的问题,高可用的部分也不是DBA 自己的事情,是一个与应用架构需要进行协商后,进行设定的工作,每种不同的设定本身都具有自己的特性,如频繁变动配置的PGCBOUNER 建议集中部署, 而数据量较少的情况下,PGBOUCNER和数据库本身来进行部署,更有效率。
PGBOUCNER的部署本身,和整体的公司的PG的数量,逻辑库的数量,以及公司管理访问数据库的规范等等都有关,如何切合实际的部署pgboucner是一个需要综合考虑的问题。
标签:POSTGRESQL,PGBOUNCER,pgbouncer,部署,数据库,连接,进行 From: https://blog.51cto.com/u_14150796/6534573