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 也能查到 連接情況。