等待事務sync超時

1 Sync等待機制

1.1 什么是sync等待

GaussDB兩階段事務，其提交順序為：先GTM提交，再CN提交，最后DN提交。同一個事務在不同節點提交次序有先后，會造成數據不一致的問題。因此我們引入了tuple級Sync等待機制：掃描到一條tuple時，如果該DN上tuple對應的事務未提交，等待該事務結束。

1.2 為什么要sync等待

考慮如下例子：

start ? transaction;

insert into t1 values(tuple1,tuple2 ? on DN1;tuple3 on DN 2)

commit;

假設上面分配的事務id為10，在commit階段，10事務現在gtm上結束，但是在DN上還未提交，假如此時有一個查詢select * from t1；那么該查詢從GTM中拿到的快照中10是已經結束的。

Case1：select 到 DN1上掃描到tuple1時，事務10還未在DN1上提交，故tuple1不可見；當在DN1上掃描到tuple2時，事務10已經提交，故tuple2可見。若無sync等待，現有邏輯會造成最終不一致。

Case2：select 到 DN1上掃描tuple1時候，事務10在DN1上已經提交，tuple1可見；select到 DN2上掃描tuple3時，事務10還未在DN2上提交，故tuple3不可見，此時造成瞬時不一致。

2 常用應急方法

從上面的介紹可以看出，等待事務sync超時的原因是某個節點的事務沒有正常提交或回滾。所以解決辦法就是找到這個事務的業務，分析不能正常提交的原因。不能正常提交可能的原因有：

l? 事務殘留

l? 事務在等鎖

l? 磁盤IO異常，或通信、xlog日志等導致IO寫滿，事務提交慢

常用的解決辦法有：

l? 殺語句

l? 找不到語句可以殺實例

l? 找不到對應的實例可以重啟

如果重啟后，重新拉起業務，又出現該問題，說明可能是磁盤存在問題，或者系統參數存在問題，需要分析其他原因，修改相關參數。

3 定位方法

3.1 等待同一個事務超時

出現這種情況，通常是等鎖或者事務殘留，我們需要想辦法找到持鎖的線程或殘留的線程，殺掉就可以了。

1.?????? 連接CN查找事務id對應的pid:

select ? * from pgxc_running_xacts where gxid=xxxx or prepared_xid=xxxx or ? next_xid=xxxx;

2.?????? 如果pid不是0，執行步驟3；如果pid是0，執行步驟5

3.?????? 根據查找到的pid找到查詢的語句等信息

select ? * from pg_stat_activity where pid=xxxx;

4.?????? 根據query_id或者pid查找等待情況

select ? * from pg_thread_wait_status where tid=pid; (上面的pid)

根據等待情況進行分析：

l? 如果沒有等待的語句，查看是否殘留。確定是殘留，后臺殺掉該線程即可；

select ? * from pgxc_prepared_xacts;

l? 如果有等待，可以進一步分析，或者殺掉等待的線程。

5.?????? 查看gs_clean日志，根據各節點的事務提交情況分析，找到與大部分實例事務狀態不一致的實例，查看日志進一步分析。

這種情況下已經找不到對應的線程，可以考慮殺掉實例進行規避。

3.2 等待的事務號一直變化

出現這種情況，通常是IO過高或者其他原因，導致事務提交慢。可以根據2.1節內容初步排查，結合其他相關日志排查IO過高等影響事務提交速度的原因：

1.?????? 查看OS日志，排查是否存在慢盤，導致io異常。

2.?????? 查看磁盤IO情況，排查是否因為日志產生較多，將IO占滿，導致事務提交很慢；

遇到這種情況，查看日志很多的實例，在postgresql.conf文件中找到生成大量日志相關的參數（例如logging_module），確認后關閉即可。

3.?????? 查看等待超時附近的日志，是否存在其他報錯，可能是其他原因導致事務不能正常提交（例如通信）。

出現等待事務sync超時的原因不僅限于以上幾種，后續會根據新場景進行補充。

4 參考文獻

MPPDB兩階段提交流程?：

http://3ms.huawei.com/hi/group/2191/wiki_5246767.html

云數據庫 GaussDB(for openGauss)

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。