叢集系統與事務處理需要注意的一點

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

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

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

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

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

本文轉自健哥的資料花園部落格園部落格，原文連結：http://www.cnblogs.com/gaojian/p/3223078.html，如需轉載請自行聯絡原作者