https://blog.csdn.net/joshua1830/article/details/51965964

1,复制模式可靠性低


最早时候使用的是复制模式,数据到pgpool然后pgpool分别写入n个postgres.发现经常出现数据不一致问题,导致最终只有一个数据库可用


2,online recovery 


基于PIRT的online recovery 配置复杂


3,基于流复制的主备模式


这个用到postgres9的新特性,前期配置测试都很easy,failover 也很好用,但是当服务连接上pgpool时,事务往往报错 postgres error : failed to read kind from backend,这个我在之前的文章中提到过,至今无法解决。


4,连接数的困扰


num_init_children 原来理解成了一个池的大小,如果超过了会自动扩增,但是实际上往往不够用,确切的说该值也是 pgpool-II 支持的从客户端发起的最大并发连接数。 


所以这个值配的尽量大些,并且对这个值的更改必须重启pgpool.


5,client_idle_limit不要配置

当一个客户端在执行最后一条查询后如果空闲到了 client_idle_limit 秒数, 到这个客户端的连接将被断开.连接不应该让pgpool来断开,应该是应用主动去断开。如果让pgpool去断开,会导致客户端不可用。




当然pgpool也有一个好处,能够快速找到连接的应用。因为每个连接都是单独的进程,所以启动后会有num_init_children 个进程可以接受连接


使用# ps -ef |grep pgpool 可以看到


pgpool: wait for connection request 的进程是空进程,等待连接。


pgpool: postgres dbtest 10.115.53.167(51883) idle 这些进程是使用中的进程,并且可以看到是来自哪台机器,什么用户,连接的是什么数据库。


当然使用select * from pg_stat_activity 也能查到 连接情况。