因?yàn)镻gpool-II采用Master/Slave模式的時候，因偶然因素導(dǎo)致Pgpool-II與 SlaveDB之間的通信中斷(L4SW主動切斷)。

而此時某事務(wù)向Master數(shù)據(jù)庫提交commit已經(jīng)成功，在向SlaveDB提交因通信中斷而失敗。

這樣，導(dǎo)致的結(jié)果是一方面向Master數(shù)據(jù)庫提交成功，另一方面向前臺程序返回出錯信息的奇怪現(xiàn)象。

(由于客戶的 fail_over_on_backend_error為假，故沒有發(fā)生failover)

這是因?yàn)?#xff0c;首先，Pgpool-II中沒有事務(wù)處理機(jī)制，或者說沒有包含Transanction Manager，如果有，那么它可以利用數(shù)據(jù)庫的兩階段提交能力，保證：要么兩個數(shù)據(jù)庫節(jié)點(diǎn)一起提交，要么一起回滾。當(dāng)然，具體到Pgpool-II中，在Master/Slave模式也不允許這么作，但至少如果有Transaction Manager，如果出現(xiàn)通訊錯，還是應(yīng)該可以roll back的。

其次，展開了想一下，就算是有事務(wù)處理機(jī)制，就能保證數(shù)據(jù)庫節(jié)點(diǎn)都提交或者都回滾了嗎？

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

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

所以完美的事務(wù)處理是不存在的，應(yīng)用和運(yùn)維人員要考慮到這一點(diǎn)，準(zhǔn)備好一旦數(shù)據(jù)在各節(jié)點(diǎn)間發(fā)生不一致后的對應(yīng)方案。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。