Pgpool烂泥扶不上墙
写这篇文章,是想好心地给打算使用Pgpool的人提个醒:
Pgpool 真的不适合在企业范围使用。
我的主要理由是:
设计陈旧:
一旦后台任何节点Down掉,都会引发failover,它会杀掉所有子进程,再重新创建子进程,在此过程中,所有事务不分青红皂白都被停止,实际上相当于被rollback。这一点引起很多次的很多客户的质疑。也许这是不得已而为之,因为它没有transaction manager。
代码混乱:
因为项目的原因,多次深入到Pgpool-II的源代码中进行调查,发现代码写的很随意,注释很随意,而对是否输出日志,输出哪种类型的日志,到底是 DEBUG,还是INFO,或者ERROR,非常的没有规律,完全看开发者的心情。
文档混乱:
其官方文档的说明,质量非常低劣。各个版本的信息集合在一起,只有一个页面。和PostgreSQL的文档组织结构相比一个在地上一个在天上。Pgpool-II有几种运行模式,如stream replication,如master/slave,然而master/slave模式的说明也就是二三十行的样子。
由于代码管理上的懈怠和文档的混乱,其文档内容和代码无法严格匹配,很多时候都有误导性的信息,例如helthcheck的设定就是如此。又由于代码管理混乱,导致旧的配置参数在新的版本里被忽视,作用受到不应有的限制,最后整个参数的性质完全扭曲。
责任心不强:
具体就不点名了,此软件的最初开发者的能力,我本人还是十分佩服的;根据公开的信息显示,此人后来担任了某公司的领导职务,在网上搜pgpool,常常可以看到其公司署名的宣传pgpool的文档。结合上述两点,我在想,他们也许利润压力很大吧。但是产品改进如果不能作好,实际上是走不远的。
未经大规模商业考验:
作为采用C语言开发的系统软件,我认为在正式发布前,至少也应该进行静态与动态检查,防止出现大规模的内存泄漏吧。然而它确实就发生了,我用网上流行的内存泄露静态检查工具都可以发现的问题,他们居然没有尽早发现,后来出现了运行一两个小时就内存泄漏1个GB的严重问题。
所以说,目前为止Pgpool还是个玩具而已。如果需要类似的功能,类似的软件多着呢,犯不着一棵树上吊死。