GaussDB(DWS)實例長期處于catchup問題分析

主、備、從高可用架構(gòu)

主、備、從數(shù)據(jù)發(fā)送的邏輯圖：

圖1-DN高可用架構(gòu)

如圖1所示，DN主備實例采用強同步模式，保證主機故障時備機有一份完整數(shù)據(jù)對外提供服務(wù)。當主備從均正常時，數(shù)據(jù)只發(fā)送給備機，從備空閑，從備正常狀態(tài)下不提供服務(wù)，備機down掉之后主機還是提供寫服務(wù)，將數(shù)據(jù)備份發(fā)送至從備。

主備同步原理

保證主備實例數(shù)據(jù)強一致性依賴數(shù)據(jù)同步機制，主要分為日志同步與數(shù)據(jù)頁同步，如圖2所示，WalSend與DataSend在主機實例上運行分別負責發(fā)送日志文件與數(shù)據(jù)頁發(fā)送至備機或從備(在備機故障情況下發(fā)送至從備)，WalReceiver與DataReceiver，在備機或從備實例運行負責接收后并有對應(yīng)線程將其落盤達到數(shù)據(jù)強一致。

圖2-主備實例數(shù)據(jù)同步框架

日志同步

主機記錄XLOG后，會定期寫到磁盤上，WalSend線程會讀取磁盤上日志，通過TCP網(wǎng)絡(luò)發(fā)送給備機WalReceiver線程，該線程接收后會寫到一個內(nèi)存隊列中，WalRecWriter線程定時從隊列里取出來寫盤，并更新備機寫盤LSN，WalReceiver線程回復(fù)主機消息時把改值發(fā)送給主機。恢復(fù)日志線程定期讀取磁盤上XLOG對日志進行REDO。

數(shù)據(jù)頁同步

主備數(shù)據(jù)同步通過XLOG事務(wù)日志同步。在大量寫事務(wù)場景下，會產(chǎn)生大量的XLOG日志，主機需要先將XLOG下盤，然后日志同步進程讀取XLOG發(fā)送給備機，備機收到XLOG日志后下盤，然后恢復(fù)進程讀取日志進行REDO。這個過程主備一共有兩次寫IO和兩次讀IO請求。

在OLAP場景中，普遍數(shù)據(jù)量都很大，并且很多場景往往只需要查詢某張表中的某一列數(shù)據(jù)，這樣通常采用列式存儲格式。不僅有利于性能提升，并且按列存儲，數(shù)據(jù)格式一樣，非常利于壓縮，節(jié)省存儲空間。由于按列存儲時，如果再按行存儲方式去導入一行記錄一條日志，那么性能將非常慢，如果沒有日志，將無法實現(xiàn)主備同步目的，因此需要探求一種新的數(shù)據(jù)同步方式。

基于上面兩個方面考慮，我們設(shè)計了數(shù)據(jù)復(fù)制通道，即數(shù)據(jù)導入到DN后，組成一個個最小存儲單元（行存按頁面大小8K為單位，列存按CU大小8K為單位），然后發(fā)送給備機，備機接收到后，將數(shù)據(jù)寫盤，并回復(fù)主機寫盤數(shù)據(jù)邏輯位置（主機發(fā)送時，給每個數(shù)據(jù)單元設(shè)置一個uint64位單調(diào)遞增的偏移位置，類似于XLOG中的LSN），主機在事務(wù)提交前，如果該事務(wù)要求寫盤數(shù)據(jù)已經(jīng)傳輸給備機那么即可提交。

圖3-數(shù)據(jù)頁同步流程

數(shù)據(jù)復(fù)制只有在行存批量導入數(shù)據(jù)和列存導入數(shù)據(jù)時觸發(fā)，如圖3所示，數(shù)據(jù)導入后，存儲層將多個數(shù)據(jù)tuple組成一個個數(shù)據(jù)最小存儲單元，并將其發(fā)到發(fā)送隊列中，DataSend線程將從發(fā)送隊列中取數(shù)據(jù)通過TCP網(wǎng)絡(luò)發(fā)送給備機DataReceiver線程，該線程接收數(shù)據(jù)后會寫到一個內(nèi)存隊列中，由DataRecWriter線程從隊列中讀取并解析出每個數(shù)據(jù)單元寫盤，并更新寫盤邏輯偏移位置，在DataReceiver回復(fù)主機消息時將該值發(fā)送給主機。數(shù)據(jù)復(fù)制過程中數(shù)據(jù)直接由DataRecWriter寫盤，不需要恢復(fù)日志線程去恢復(fù)數(shù)據(jù)。

注：主備同步常用視圖：

select * from pgxc_get_senders_catchup_time();

主備同步常見問題

場景一：業(yè)務(wù)慢，集群狀態(tài)長時間有catchup

【問題描述】

業(yè)務(wù)變慢，查看集群狀態(tài)多對實例處于catchup狀態(tài)

【機制說明】

該場景下catchup原因一般都是由于某些業(yè)務(wù)在短時間內(nèi)產(chǎn)生較多xlog文件，主備同步不及時，此時主備同步有排隊情況影響事務(wù)提交導致業(yè)務(wù)出現(xiàn)比較卡的現(xiàn)象。

造成該問題主要有帶索引導入、頻繁delete、頻繁truncate、update導致，此時需要解析xlog查看對應(yīng)操作以及相關(guān)業(yè)務(wù)表。

對于此類問題我們主要任務(wù)是通過解析xlog找出對應(yīng)表讓業(yè)務(wù)側(cè)溝通進行整改。

【問題分析】

進入某一catchup實例路徑，使用pg_xlogdump解析其中一個xlog文件: pg_xlogdump $xlog_filename

帶索引導入場景：

頻繁delete或delete整張表場景：

2、通過解析xlog當中database與表對應(yīng)OID解析該表所在庫以及對應(yīng)表名，以便業(yè)務(wù)側(cè)排查

對應(yīng)庫與表OID如上紅框所示，連接對應(yīng)DN通過以下命令查到該表對應(yīng)數(shù)據(jù)庫、schema與表名

select * from pg_database where oid = xxxx;

select * from pg_class where relfilenode = xxxx;

select * from pg_namespace where oid = xxxx

注：若確定進入庫沒有問題，對應(yīng)表在pg_partition或pg_class中都找不到，說明該表被刪除或正在創(chuàng)建事務(wù)還未提交可執(zhí)行以下命令后查詢（該只讀事務(wù)在退出當前會話后會自動回滾）：

start transaction read only;

set enable_show_any_tuples = true;

set enable_indexscan = off;

set enable_bitmapscan = off;

【問題結(jié)論&&建議】

1、帶索引表入庫產(chǎn)生大量xlog日志同步不及時導致catchup，影響事務(wù)提交引起業(yè)務(wù)卡。

2、建議入庫前刪除索引，入庫完成后進行索引重建。

3、業(yè)務(wù)側(cè)盡量避免對單張表進行頻繁update、delete、truncate操作。

場景二：集群狀態(tài)長時間處于catchup狀態(tài)（超過24小時）

【問題描述】

查看集群狀態(tài)或查看追趕視圖長時間（超過24小時甚至更長時間）有實例處于catchup狀態(tài)

【問題分析】

問題定界：查看主實例日志是否有鎖超時日志，若主實例有相關(guān)超時日志說明為此場景，按照問題修復(fù)方案整改即可。

【問題修復(fù)】

出現(xiàn)該問題是由于catchup與dml語句搶鎖導致，主實例鎖超時日志會打印搶鎖語句，此時kill正在執(zhí)行的dml語句即可（關(guān)注最新鎖超時語句即可），繼續(xù)觀察主實例日志確保無鎖超時日志說明是正常情況等待catchup結(jié)束即可；若kill業(yè)務(wù)后頻繁有所超時日志建議與客戶協(xié)商停止業(yè)務(wù)讓catchup做完，不然可能會與新進來的業(yè)務(wù)一直搶鎖導致catchup無法結(jié)束。

排查步驟如下：

1、確認catchup以及主實例：

cm_ctl query –Cvd|grep Catchup

查詢集群實例catchup狀態(tài)如下：

1 10-x-179-67 6001 /srv/BigData/mppdb/data1/master1 P Primary Normal | 2 10-x-179-95 6002 /srv/BigData/mppdb/data1/slave1 S Standby Catchup|

3? ASG003? 3002 /srv/BigData/mppdb/data1/dummyslave1 R Secondary Normal

2? 10-x-179-95 6007 /srv/BigData/mppdb/data2/master2???? P Primary Normal | 1? 10-x-179-67 6008 /srv/BigData/mppdb/data1/slave2????? S Standby Catchup |

3? ASG003 3005 /srv/BigData/mppdb/data2/dummyslave2 R Secondary Normal

根據(jù)以上結(jié)果catchup實例為6002，對應(yīng)主實例為6001。

2、查看對應(yīng)主實例日志

使用omm用戶登錄6001實例所在節(jié)點加載環(huán)境變量后進入日志目錄：

cd $GAUSSLOG/dn_6001

3、在最新日志文件查看catchup線程號：

grep "catchup" postgresql-2021-xxx.log

查看catchup線程啟動日志如下：

2020-07-30 11:26:58.666 5f20d1aa.3012 [unknown] 281454775105184 [unknown] 0 dn_6001_6002 00000 0 [BACKEND] LOG: ?catchup process start to search all bcm files.

2020-07-30 11:57:25.874 5f20d1aa.3012 [unknown] 281454775105184 [unknown] 0 dn_6001_6002 00000 0 [BACKEND] LOG: ?catchup process start to search all bcm files.

4、使用catchup線程查看是否有鎖超時信息

grep "281454775105184" postgresql-2021-xxx.log

查看catchup線程啟動日志如下：

2020-07-30 11:03:34.275 5f20d1aa.3012 [unknown] 281454775105184 [unknown] 0 dn_6001_6002 00000 0 [BACKEND] LOG: ?catchup process start to search all bcm files.

2020-07-30 11:26:57.558 5f20d1aa.3012 [unknown] 281454775105184 [unknown] 0 dn_6001_6002 00000 0 [BACKEND] LOG: ?thread 281454775105184 still waiting for ExclusiveLock on relation 18486641 of database 112877 after 1200000.124 ms

2020-07-30 11:26:57.558 5f20d1aa.3012 [unknown] 281454775105184 [unknown] 0 dn_6001_6002 YY003 0 [BACKEND] ERROR: ?Lock wait timeout: thread 281454775105184 on node dn_6041_6042 waiting for ExclusiveLock on relation 18486641 of database 112877 after 1200000.124 ms

2020-07-30 11:26:57.558 5f20d1aa.3012 [unknown] 281454775105184 [unknown] 0 dn_6001_6002 YY003 0 [BACKEND] DETAIL: ?blocked by hold lock thread 281420014876320, statement

2020-07-30 11:26:58.666 5f20d1aa.3012 [unknown] 281454775105184 [unknown] 0 dn_6001_6002 00000 0 [BACKEND] LOG: ?catchup process start to search all bcm files.

如上結(jié)果主實例日志最近時間存在Lock wait日志

鎖超時日志下一條日志為對應(yīng)持鎖業(yè)務(wù)如下：

ERROR: ?Lock wait timeout: thread 281454775105184 on node dn_6041_6042 waiting for ExclusiveLock on relation xxof database xx after xx ms

DETAIL: ?blocked by hold lock thread 281420014876320, statement , hold lockmode RowExclusiveLock.

4、連接CN查看活躍語句視圖找出持鎖業(yè)務(wù)：

select * from pgxc_stat_activity where query like '%$table_name%';

5、與客戶協(xié)商后停掉該業(yè)務(wù)：

select pg_terminate_backend($pid);---$pid值見第上一步查詢結(jié)果

6、繼續(xù)觀察主實例日志沒有鎖超時日志即可說明在正常同步等待即可，若還存在鎖超時日志繼續(xù)排查即可

總結(jié)：

1）其他報錯場景：

物理文件損壞：

WARNING invalid page in block xxxx

ERROR：remote read failed from xxx

BCM文件殘留：

ERROR: could not open file "base/xx/xxx"：No such file or directory

2）此問題觸發(fā)原理：

拉起catchup線程同步數(shù)據(jù)頁 -> 數(shù)據(jù)頁面加鎖 -> 主機datasender讀取頁面并發(fā)送 -> 備機datareceiver接收

拉起catchup線程同步數(shù)據(jù)頁 -> 加鎖失敗 -> 讀取頁面失敗 -> 備機datareceiver接收

附

GaussDB(DWS)高可用之數(shù)據(jù)復(fù)制

GaussDB(DWS)高可用之備機重建

GaussDB(DWS)高可用之主備從HA技術(shù)

EI企業(yè)智能 Gauss AP 數(shù)據(jù)倉庫服務(wù) GaussDB(DWS)

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

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