pgpool-II的緻命弱點

在health_check_period 有效的情況下，當 pgpool-II 所連接配接的節點如果有了故障，

會引發如下幾件事：

1  在main.c的主循環中标記出故障的節點不可用(log中會看到：類似set 1 th backend down status)，

2 然後調用 failover()函數，切斷所有的連接配接(kill 所有process：log中會看到：Restart all children)；

3 再然後，重新開始對尚且有效的各節點進行連接配接

(重新建立一堆子程序：log中會看到：pcp child process received restart request)

設想一下我們正在通過pgpool來執行一個transaction。

    如果尚未送出，發生了某節點故障，

       那麼對剩餘的正常節點而言，

       failover()會導緻向各個節點未送出的内容沒有commit的機會，故此各個節點都是資料一緻的。

   但如果恰恰是在對各個節點送出的時候，發生了某節點故障，導緻failover()呢？

       那麼會發生某個節點已經發送commit指令成功，向某些節點發送commit指令之前，連接配接被切斷。

       這樣就産生了資料不一緻了。 這種事情，雖然發生機會很低，但是已經切實地發生過。

pgpool作為一個第三方的，獨立于postgresql 的開源産品，還是有點尴尬的。

它如果不引入 transaction manager來進行 類似于兩階段送出的控制，而是僅僅一行一行地發送用戶端的指令給postgresql ，必然會在最壞的情況下，産生出：

由于故障發生退化(failover), 由切斷所有連接配接導緻正常節點間出現資料不一緻。

又由于failover_if_affected_tuples_mismatch)設定，

導緻再次發生退化，進入惡性循環，最壞的情況下，隻剩下一個master節點可用。

要想解決這個問題，除非pgpool開發者痛下決心，引入transaction manager，

或者提供高層API，供用戶端程式調用。而不再是那種在用戶端和資料庫節點間處于透明的中介地位。

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