摘要：
写这篇文章，是想好心地给打算使用Pgpool的人提个醒：Pgpool 真的不适合在企业范围使用。我的主要理由是：设计陈旧： 一旦后台任何节点Down掉，都会引发failover，它会杀掉所有子进程，再重新创建子进程，在此过程中，所有事务不分青红皂白都被停止，实际上相当于被rollback。这一点引起很多次的很多客户的质疑。也许这是不得已而为之，因为它没有transaction manager。代码混乱: 因为项目的原因，多次深入到Pgpool-II的源代码中进行调查，发现代码写的很随意，注释很随意，而对是否输出日志，输出哪种类型的日志，到底是 DEBUG，还是INFO，或者... 阅读全文
摘要：
因为Pgpool-II采用Master/Slave模式的时候，因偶然因素导致Pgpool-II与 SlaveDB之间的通信中断(L4SW主动切断)。而此时某事务向Master数据库提交commit已经成功，在向SlaveDB提交因通信中断而失败。这样，导致的结果是一方面向Master数据库提交成功，另一方面向前台程序返回出错信息的奇怪现象。(由于客户的 fail_over_on_backend_error为假，故没有发生failover)这是因为，首先，Pgpool-II中没有事务处理机制，或者说没有包含Transanction Manager，如果有，那么它可以利用数据库的两阶段提交能力，保 阅读全文
摘要：
http://www.onlamp.com/pub/a/onlamp/2004/11/18/slony.html 我特别喜欢这篇文章，就进行了转载和翻译。Introducing SlonybyA. Elein MustainSlony is the Russian plural for elephant. It is also the name of the new replication project being developed by Jan Weick. The mascot for Slony, Slon, is a good variation of the usual Post 阅读全文
摘要：
我的看法是：日志一定要能够起到提供切实有效的信息的作用。如果作为原有产品开发维护人员，只要客户给你打个电话，报一下日志中的错误、警告号码或信息，你立即就可以知道具体哪个模块的哪个函数出错了，这是最好的。没有产品是完美的，一个可以很快定位错误便于修正的产品是一个相对理想的选择。那种产品卖出去就拉倒了，bug定位很慢，更新补丁不及时的公司，客户在暗叹倒霉的同时，会很生气的，后果会很严重！我的建议是这样：例如A模块调用B模块，B模块调用C模块A模块中日志信息输出格式(假定为log级别，而不是error或fatal级别)：log_A_001log_A_002log_A_003...B模块中日志信息输出 阅读全文
摘要：
客户来邮件，问到：为何我们所用的软件产品，输出日志中有FATAL:xxxx 之类的，然后反复发生对同一模块调用，直到成功为止。那么，这个软件当初的设计就是这样的吗？言外之意，它是一个Bug吗？在我看来，一个产品，无论它是开源的，还是封闭的商业软件，都需要注意一个问题：对于挑剔的客户而言，不要说FATAL或ERROR字眼，就是日志中有WARNING，客户也会不放心，也有可能引发疑虑呢。解决的方法:要么尽量不要在编程的时候太过随意，开发人员不能想输出什么就胡乱用FATAL/ERROR/PANIC/WARNING之类的标记。对信息分类设定严格标准，并建立一套简明实用的可以Guideline，从客户运 阅读全文