因為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的。

其次，展開了想一下，就算是有事務處理機制，就能保證數據庫節點都提交或者都回滾了嗎？

實際上，事務處理也就是利用所謂預提交方式，保證大家都預提交成功后，再一起真正提交或者一起真正回滾。

那如果"真"提交的時候出錯了呢？還是說再搞三階段提交、四階段提交？

所以完美的事務處理是不存在的，應用和運維人員要考慮到這一點，準備好一旦數據在各節點間發生不一致后的對應方案。

總結

以上是生活随笔為你收集整理的集群系统与事务处理需要注意的一点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。