知识的学习是越学越不会,越学发现的"黑洞"和自己的欠缺就会越多,所以一直报以心虚的状态来学,可能理解多年的东西他变化了,或者当初就没有理解的彻底,而不自知.
Pgbouncer 看似是一个轻量级的连接缓冲,今天就来整理一下,来看看知识的黑洞
我的pgbouncer 到底是应该是和PostgreSQL 安装在一起,还是和别的数据库中间件一样单独安装或者DOCKER 安装.
个人认为,pgbouncer属于轻量级的缓冲池程序,和postgresql本身部署在一起,并没有什么不妥,从功能上来讲比较单一,并没有特别复杂的功能,例如读写分离,或者语句的变更,或者语句的审核等复杂的功能, pgbouncer 就是要提高postgresql的进程连接的复用,提高postgresql 的处理高并发连接中的性能表现.应该是一个PG 自己安装一套pgbouncer, 这里对比proxysql 功能和特点完全不一致,虽然都是数据库的中间件缓冲.
我修改了pgbouncer 的配置,我在从启动中连接会断吗? 会有多大的影响.
1 你的pool mode 是session, 在我们并发3000连接中,重启动,整体的连接失效,程序报错2 你的pool mode 是 transaction 我们还是并发3000连接,重启动,在重启动,设置suspend 的状态是,正常工作的连接失效, 后续重启动完毕后,连接立即复原.从影响性方面也分两个面来说,如果你是session 则你整体的这个session 会断掉,如果你业务繁忙,则非常不建议你,随便的进行重启的活动transaction 方面,因为连接的特性使然,如果在少量业务(低峰期),必须要重启,还是可以考虑重启动,
但怎样都避免不了,连接要报错的必然,所以对于某些新建库,新加应用的场景,还请相关人员考虑,在非业务,或低峰期,与业务和商量好,在进行相关操作.
postgresql 有高可用,但pgbouncer 有没有高可用,如果没有怎么办?
在默认的情况下,PG的集群中应该只有一台服务器提供写服务, 如果将pgbouncer 与pg安装在一起,则这个问题并没有意义, 因为pgbouncer 并不提供判断主从的功能,并且也不提供故障转移的功能,所以如果通过VIP 的方式访问,则与pgbouncer 高可用没有关联.在使用pgbouncer 的过程,中,如果出现网络问题,或者数据库本身无法和pgboucner连接的情况后,网络或数据库的服务在恢复后,到底连接会怎么样,
例如我正在查找一张大表, 网络闪断,或服务器重启.举例,我们查询一个表的200行记录, 图一是不使用pgbouncer 查询的截图,图二 是使用pgbouncer 后的截图.从上图可以看到,在服务器无响应的情况下, pgbouncer 到底做了什么, 如果光从应用和数据库连接中的故障处理来说,其实还好, 但如果将Pgbouncer 安装在数据库一端,这样其实对应用有的时候是隐蔽了某些关于服务器方面的例如重启,或者其他方面的问题,在程序端可能一方看是减少了报错的,那么问题的分析方和反映方就变换为了数据库端.那么问题可以在深入一点,如果此时没有查询,那pgboucner的 日志中还会有刚才的体现吗? 结果是不会.在使用pgbouncer的情况下, 如果设置了使用了transaction ,但是连接中设置了与session等级的配置参数,将不会起作用, 同时即使使用了 session的方式,也会因为下面的配置而出现不同的结果.具体请查询相关的参数解释,另外在使用transaction 模式,但应用程序对访问有针对session 方式的强相关性,也会出现问题,请相关的架构设计和程序人员能在程序设计时考虑.
