集群系统与事务处理需要注意的一点

因为Pgpool-II采用Master/Slave模式的时候，因偶然因素导致Pgpool-II与 SlaveDB之间的通信中断(L4SW主动切断)。

而此时某事务向Master数据库提交commit已经成功，在向SlaveDB提交因通信中断而失败。

这样，导致的结果是一方面向Master数据库提交成功，另一方面向前台程序返回出错信息的奇怪现象。

(由于客户的 fail_over_on_backend_error为假，故没有发生failover)

这是因为，首先，Pgpool-II中没有事务处理机制，或者说没有包含Transanction Manager，如果有，那么它可以利用数据库的两阶段提交能力，保证：要么两个数据库节点一起提交，要么一起回滚。当然，具体到Pgpool-II中，在Master/Slave模式也不允许这么作，但至少如果有Transaction Manager，如果出现通讯错，还是应该可以roll back的。

其次，展开了想一下，就算是有事务处理机制，就能保证数据库节点都提交或者都回滚了吗？

实际上，事务处理也就是利用所谓预提交方式，保证大家都预提交成功后，再一起真正提交或者一起真正回滚。

那如果"真"提交的时候出错了呢？还是说再搞三阶段提交、四阶段提交？

所以完美的事务处理是不存在的，应用和运维人员要考虑到这一点，准备好一旦数据在各节点间发生不一致后的对应方案。