PostgreSQL資料庫事務出現未知狀態的處理方法，postgresql處理方法

PostgreSQL資料庫事務出現未知狀態的處理方法，postgresql處理方法

背景

資料庫的事務是原子操作，要麼成功，要麼失敗。但是實際上在用戶端的視角，可能有第三種狀態：unknown狀態。

當用戶端提交事務結束（rollback , commit , prepare xact , rollback pxact , commit pxact）的請求後，資料庫收到請求，資料庫可能執行失敗，也可能執行成功，不管怎樣都要寫對於的WAL日誌，還有CLOG，然後資料庫要將執行結果返回給用戶端ACK。

這裡存在幾種可能，導致用戶端不知道執行到底怎麼樣了？

收到用戶端請求後，資料庫沒有返回任何ACK給用戶端，用戶端對這次請求很茫然，它只能人為資料庫處於UNKNOWN的狀態。

UNKNOWN 事務的處理

unknown事務，就是用戶端沒有收到commit/rollback ACK的事務。不知道是成功還是失敗。

多節點(quorum based sync replication)與單節點都可能出現UNKNOWN事務，效果、形態一致。

如何處理unknown事務呢？

unknown事務分為以下幾種情況.

rollback , commit , prepare xact , rollback pxact , commit pxact 幾種情況的unknown處理方法：

1、兩階段解決unknown狀態問題

prepare 階段unknown, 切換leader後，用戶端通過pg_prepared_xacts視圖檢查prepare xact狀態，如果沒有prepare xact則說明失敗了，那麼整個事務重新發起即可。如果prepare xact存在，說明prepare xact成功了。

commit or rollback prepare xact階段unknown, 切換後檢查prepare xact狀態，存在則重試commit or rollback prepare xact。不存在則說明已經成功（我們認為2PC是一定成功的），無須處理。

2、非兩階段事務，rollback unknown無須處理，rollback失敗或成功對於用戶端來說結果是一樣的。因為不管怎樣都會復原掉，這是資料庫原子性保障的。

3、非兩階段事務，commit unknown處理，極度嚴謹的情境，程式可以設計事務狀態可回溯，例如：

事務開始時，記錄事務號或唯一流水號，事務號在資料庫中是一個唯一的流水，可以根據事務號查詢它的狀態，比如postgresql。

但是並不是所有資料庫都有這種介面，比如非物理流式複製的資料庫，則可以在事務中增加全域唯一流水號來查看事務是否提交。這裡利用了事務的原子特性，既要麼全成功要麼全失敗。可以舉個使用例子。

使用業務流水實現事務狀態判斷的例子：

begin; 
產生唯一業務流水ID, 寫入到某個流水表，同時在程式或其他資料庫中記錄這個流水號，備查。 
執行事務 
提交事務； 
 
-- 出現unknown 
 
通過唯一業務流水ID，查詢資料庫中是否存在這條記錄。 
如果不存在，說明事務提交失敗。 
如果存在，說明事務提交成功。（因為資料庫的事務是原子操作）