pgpool使用中遇到的坑总结

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 也能查到 连接情况