GaussDB(DWS)集群狀態異常問題處理套路

GaussDB(DWS)集群故障問題處理套路

【使用前提】

加載環境變量（僅線下純軟形態需要）：source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile

build相關日志路徑：$GAUSSLOG/bin/gs_ctl

cm_agent日志路徑：$GAUSSLOG/cm

實例日志路徑：$GAUSSLOG/pg_log/dn_xx

系統日志（僅root用戶）：/var/log/message

【試用場景】

本方案適用以下場景：實例故障導致集群降級或不可用、實例狀態長時間處于catchup狀態、單實例目錄下pg_xlog文件積壓。碰到以上場景按照對應方案處理，根據實例狀態找到對應案例或處理步驟進行處理。如下表：

維度

使用場景

確認方式

明確問題場景

集群降級

cm_ctl query

集群不可用

cm_ctl query

實例目錄pg_xlog較大

實例長期處于catchup

cm_ctl query -Cvd

實例重啟或主備切換

cm_ctl quer -Cvds

1 集群降級狀態，業務可以正常連接

集群狀態為degraded狀態，該場景下業務可以正常連接，按照故障實例狀態找到對應處理案例進行恢復。故障實例狀態與處理見下表：

Check項

異常值

處理方式

Check方法

實例狀態

Need repair

1.1章節

cm_ctl query –Cv

Pending starting

1.2章節

Disk damaged

1.3章節

Down unknown

1.4章節

Build failed

1.5章節

Manually stopped

1.6章節

1.1 Need repair

若碰到實例狀態為need repair狀態按照以下步驟進行排查。

cm_ctl query –Cvd|grep -i "Need repair"

查詢異常實例狀態如下：

1? 10-185-179-67 6001 /srv/BigData/mppdb/data1/master1??? P Primary Normal |

2 10-185-179-95 6002 /srv/BigData/mppdb/data1/slave1 S Standby Need repair(Normal) |

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

若為redo狀態則為正常狀態，等待自己恢復即可；若未進行redo則按照后續步驟繼續進行排查。判斷實例redo方案如下：

https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=75275

該場景下實例處于standby need repair狀態，查看異常實例最新pg_log日志（該日志在$GAUSSLOG/pg_log/dn_xx路徑下）是否有如下關鍵日志：

編號

日志內容

處理方案

1

PANIC

聯系華為工程師

2

could not connect to the primary server: GSSAPI

步驟四

排查pg_log按照對應處理方案處理。

方案一：從前臺關閉kerbos，注意該方式會自動重啟集群生效，業務會中斷。

方案二：在后臺關閉kerbos，該方案不需要重啟集群，但是可能會存在前臺kerbos狀態與后臺不一致情況，對業務無影響。后臺關閉kerbos命令如下：

gs_ssh -c "gs_om -t kerberos -m uninstall -U omm"

1.2 Pending starting

該狀態下與1.1排查思路相同，部分場景可能會有差別，排查步驟如下：

cm_ctl query –Cvd|grep -i "Pending Starting"

其中6001為故障dn實例編號，具體排查時替換為對應故障實例編號，狀態如下：

1? 10-185-179-67 6001 /srv/BigData/mppdb/data1/master1??? P Primary Normal |

2 10-185-179-95 6002 /srv/BigData/mppdb/data1/slave1 S Pending Starting |

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

若實例長時間處于pending starting，則該實例大概率進行redo為正常狀態，等待自己恢復即可；若未進行redo則按照后續步驟繼續進行排查。判斷實例redo方案如下：

https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=75275

若實例狀態在pending starting與其他狀態來回切換則說明可能該實例有文件損壞。

查看異常實例最新pg_log日志（該日志在$GAUSSLOG/pg_log/dn_xx路徑下）是否有如下關鍵日志：

其中6001為故障dn實例編號，具體排查時替換為對應故障實例編號，狀態如下：

編號

日志內容

1

The parameter destMax is equal to zero or larger than macro

2

PANIC

若日志中以上任意一個日志則符合該場景，實例狀態不會自行恢復需要人為干預，聯系華為工程師進行修復。若排查pg_log后發現不屬于該場景請聯系華為工程師進行處理。

編號

日志內容

處理方案

1

Input/output error

2

Cannot allocate memory

http://rnd-dayu.huawei.com:8081/index.php/Question/detail?id=56912

3

Could not create semaphores

http://rnd-dayu.huawei.com:8081/index.php/Question/detail?id=37396

按照以上應急方案進行處理

1.3 Disk damaged

實例為該狀態下不會自行恢復，按照以下步驟進行逐一排查

cm_ctl query –Cvd|grep 6001

其中6001為故障dn實例編號，具體排查時替換為對應故障實例編號，狀態如下：

1? 10-185-179-67 6001 /srv/BigData/mppdb/data1/master1??? P Primary Normal |

2 ?10-185-179-95 6002 /srv/BigData/mppdb/data1/slave1 S disk damaged |

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

根據集群狀態可以看到異常實例以下信息

異常實例所在節點為：10-185-179-95

異常實例路徑為：/srv/BigData/mppdb/data1/slave1

根據步驟一查到異常實例信息，使用omm用戶登錄至異常實例所在節點（10-185-179-95）查看磁盤使用情況

df -lh

10-185-179-67:~ # df -lh

Filesystem????? Size? Used Avail Use% Mounted on

/dev/sda2?????? 823G? 122G? 701G? 15% /

udev???????????? 95G? 248K?? 95G?? 1% /dev

tmpfs??????????? 95G? 1.8M?? 95G?? 1% /dev/shm

/dev/sdd1?????? 2.5T? 650G? 1.9T? 26% /srv/BigData/mppdb/data2

/dev/sdc1?????? 2.5T?? 34M? 2.5T?? 1% /srv/BigData/mppdb/data3

/dev/sde1?????? 2.5T? 2.5T? 0? 100% /srv/BigData/mppdb/data1

/dev/sdb1?????? 2.5T?? 34M? 2.5T?? 1% /srv/BigData/mppdb/data4

根據排查結果發現異常實例所在磁盤使用率已經達到100%，此時聯系華為工程師處理！！若磁盤使用率遠遠未達到100%繼續進行排查。

【排查&&處理方案】

查看主機BMC監控頁面是否有告警，若BMC監控頁面存在磁盤告警則說明磁盤故障。

手動在實例目錄所在磁盤創建文件是否能夠成功，若能成功創建則磁盤正常。否則說明磁盤故障

若存在磁盤故障請聯系硬件工程師對磁盤進行排查。硬件故障修復后對該實例按照gs_repalce方案進行修復，參考標準方案：

https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=145788

df -lh

10-185-179-67:~ # df -lh

Filesystem????? Size? Used Avail Use% Mounted on

/dev/sda2?????? 823G? 122G? 701G? 15% /

udev???????????? 95G? 248K?? 95G?? 1% /dev

tmpfs??????????? 95G? 1.8M?? 95G?? 1% /dev/shm

/dev/sdd1?????? 2.5T? 650G? 1.9T? 26% /srv/BigData/mppdb/data2

/dev/sdc1?????? 2.5T?? 34M? 2.5T?? 1% /srv/BigData/mppdb/data3

/dev/sdb1?????? 2.5T?? 34M? 2.5T?? 1% /srv/BigData/mppdb/data4

如上結果磁盤掛載少了data1，若屬于該情況使用以下命令進行掛載：

mount -a

掛載成功后對該盤所在實例使用gs_replace進行修復。若未成功掛載請聯系操作系統工程師進行排查。

gs_replace修復方案：

https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=145788

根據步驟一查到異常實例路徑為：/srv/BigData/mppdb/data1/slave1

ll /srv/BigData/mppdb/data1/slave1

若該目錄為空或者不存在則按照實例修復方案進行修復。具體修復方式見標準方案：

https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=145788

1.4 Down unknown

該狀態下實例無法自行恢復，請參考以下場景進行恢復

步驟一：查看異常實例信息

cm_ctl query –Cvd|grep 6001

其中6001為故障dn實例編號，具體排查時替換為對應故障實例編號，狀態如下：

1? 10-185-179-67 6001 /srv/BigData/mppdb/data1/master1??? P Primary Normal |

2 10-185-179-95 6002 /srv/BigData/mppdb/data1/slave1 S Down Unknown |

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

根據集群狀態可以看到異常實例以下信息

異常實例所在節點為：10-185-179-95

異常實例路徑為：/srv/BigData/mppdb/data1/slave1

步驟二：確認該實例是否存在文件損壞

查看該實例最新日志（$GAUSSLOG/pg_log/dn_xxx）是否存在以下關鍵字：

編號

日志內容

1

Input/output error

若存在該報錯由于磁盤壞道等硬件故障導致，確認磁盤無異常后請聯系華為工程師進行處理。

步驟三：確認system_call日志

查看該實例所在節點最新system_call日志（$GAUSSLOG/pg_log/cm_agent/system_call-xxx-curent.log）是否存在以下關鍵字：

編號

日志內容

1

invalid value for parameter

若出現該關鍵字說明配置文件被異常修改，查看對應備機實例或者其他實例該參數如何配置，正確修改該實例目下postgresql.conf即可自行恢復。

若按照以上步驟排查完均不符合請聯系華為工程師處理。

1.5 Build failed

【原因分析】

實例未該狀態不會自行恢復，可以不需要做排查按照修復方案進行修復，若需要分析該狀態原因可以查看gs_ctl（$GAUSSLOG/bin/gs_ctl）日志報錯提示，一般有以下幾個原因：

1）xlog被回收

2）build過程中與主機網絡閃斷

【問題修復】

通過gs_replace方案進行修復：

https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=145788

若使用該方案仍然無法恢復請聯系華為工程師處理。

1.6 Manually stopped

該狀態為現場手動停止，需要跟現場了解手動停止原因，若無數據損壞等故障場景則可手動拉起該實例。手動啟實例命令如下：

cm_ctl start -n $nodeid -D xxxx

2 集群不可用，業務中斷

集群狀態為unavailable狀態，該類型集群故障我們目標在于先將其恢復至降級狀態，恢復業務后再根據第一章繼續進行恢復。集群不可用實例故障組合狀態較多，常見類型如下表：

Check項

異常值

說明

Check方法

實例狀態

主

備

cm_ctl query –Cv

Down unkown/

Disk damaged/

Pending starting/

need repair/

build failed

promoting

故障場景下備機升主時長時間未成功

promoting

demoting

手動進行集群均衡時長時間不成功

down unkown/

disk damaged

need repair

實例故障時主實例未觸發升主流程

Need repair/

pending starting

need repair

實例故障時主實例未觸發升主流程

從備down unkown 集群不可用

om_monitor進程異常

2.1備：promoting主：down unkown/disk damaged/pending starting/need repair/build failed

cm_ctl query –Cvd|grep 6001

其中6001為故障dn實例編號，具體排查時替換為對應故障實例編號，狀態如下：

1? 10-185-179-67 6001 /srv/BigData/mppdb/data1/master1 P Pending Need repair |

2 10-185-179-95 6002 /srv/BigData/mppdb/data1/slave1 S Standby Promoting |

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

根據集群狀態可以看到異常實例以下信息：

6002處于promoting

6001處于pending need repair

該場景屬于此章節實例狀態組合場景，該狀態持續時間較長（超過30min）說明為異常情況，按照步驟二進行排查。

實例狀態為以上組合時，說明主實例故障備機觸發升主流程若該狀態保持較長時間（超過半小時）則為異常情況，只需要關注promoting實例為何長時間無法升主，具體排查與修復方案參考以下鏈接：

https://bbs.huaweicloud.com/blogs/239867

2.2 主：promoting；備：demoting

cm_ctl query -Cvd|grep 6001

其中6001為故障dn實例編號，具體排查時替換為對應故障實例編號，狀態如下：

1 10-x-179-67 6001 /srv/BigData/mppdb/data1/master1 P Standby Wait promoting |

2 10-185-179-95 6002 /srv/BigData/mppdb/data1/slave1 S Primary Demoting |

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

根據集群狀態可以看到異常實例以下信息：

6002處于Standby Wait promoting

6001處于Primary Demoting

該場景屬于此章節實例狀態組合場景，該場景出現在手動執行均衡集群時出現，持續時間較長（超過30min）說明為異常情況，按照步驟二進行排查。

主機為promoting備機為demoting，該場景為現場手動均衡集群時長時間未成功（超過半小時），則按照均衡集群失敗帖子排查：

https://bbs.huaweicloud.com/blogs/203410

2.3 主：need repair/pending starting；備：need repair

cm_ctl query –Cvd|grep 6001

其中6001為故障dn實例編號，具體排查時替換為對應故障實例編號，狀態如下：

1 10-x-179-67 6001 /srv/BigData/mppdb/data1/master1 P Pending Starting |

2 10-x-179-95 6002 /srv/BigData/mppdb/data1/slave1 S Standby Need repair(Normal) |

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

根據集群狀態可以看到異常實例以下信息：

6001處于Pending Starting

6002處于Standby Need repair(Normal)

該場景屬于此章節實例狀態組合場景，持續時間較長（超過10min）說明為異常情況，按照步驟二進行處理。

該場景下由于主實例異常退出被重新拉起后沒能redo完恢復至故障前狀態，cm_server未觸發仲裁機制，導致集群不可用。

手動停止6001實例，待備機6002觸發升主流程進行恢復，若停止后有實例長時間處于promoting（超過半小時）則按照2.1章節進行排查。

cm_ctl stop -n 1 -D /srv/BigData/mppdb/data1/master1

2.4 從備實例down unknown，集群不可用

cm_ctl query –Cvd|grep Down

其中6001為故障dn實例編號，具體排查時替換為對應故障實例編號，狀態如下：

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 Normal|

3? ASG003? 3002 /srv/BigData/mppdb/data1/dummyslave1 R Down Unknown

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 Normal |

3? ASG003??????? 3005 /srv/BigData/mppdb/data2/dummyslave2 R Down Unknown

根據集群狀態可以看到 ASG003所在節點兩個從備實例3002與3005都為Down Unknown狀態。

使用omm用戶登錄ASG003節點查看是否有兩個om_monitor進程

ps -ef|grep om_monitor|grep -v grep

若存在手動kill兩個om_monitor進程，待自動拉起后集群狀態恢復正常。

3 xlog積壓

xlog積壓場景一般體現在磁盤使用率較高，或者某一磁盤使用率明顯高于其他磁盤。根據磁盤100%排查方案進行排查時發現，部分實例路徑下pg_xlog目錄過大（超過100G）可參考此修復方案。

步驟一：查看實例xlog文件大小信息

du -sh /srv/BigData/mppdb/data1/master1/pg_xlog

其中/srv/BigData/mppdb/data1/master1為實例路徑，若該大小超過100G則按以下方案處理

步驟二：xlog積壓排查

場景

說明

Check方法

延遲xlog文件回收

備份過程中產生該文件，該文件存在不會對xlog進行回收

查看積壓實例下是否存在delay_xlog_recycle文件并且此時無備份任務。

復制槽異常

復制槽推進后才會回收xlog，復制槽推進異常時會影響xlog回收

連接對應dn查詢：

select * from pg_get_replication_slots();

查看兩條記錄（主備與主從）restart_lsn字段是否相差較多。

checkpoint失敗（較少）

xlog回收由checkpoint觸發

pg_controldata $path

$path為實例路徑

查看Latest checkpoint location值是否較小

wal_keep_segments

控制保留xlog文件個數

連接dn查詢：

show wal_keep_segments;

查看改值是否過大（1024以下均正常）

具體排查方案及處理見以下鏈接：

https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=83191

4 實例處于catchup狀態

cm_ctl query –Cvd|grep Catchup

其中6001為故障dn實例編號，具體排查時替換為對應故障實例編號，狀態如下：

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

根據集群狀態可以看到6002與6008處于catchup狀態。

根據步驟一查看實例狀態有實例處于catchup狀態，該狀態持續時間較長（超過12~24小時）或業務反饋慢均為異常情況，需要人工排查catchup原因，通常影響實例catchup因素見下表：

場景

說明

Check方法

帶索引導入、delete單表

業務異常產生較多xlog

解析主實例日志是否有較多delete或者Btree insert等關鍵字類型日志，解析命令如下：

pg_xlogdump $xlogfile

$xlogfile為任意xlog文件

鎖沖突（數據頁）

業務語句與catchup線程搶鎖

查看主實例最新pg_xlog日志是否存在以下關鍵字：ERROR: ?Lock wait timeout

bcm文件殘留、bcm文件損壞

根據bcm文件未找到應數據文件，catchup線程反復被拉起

查看主實例最新pg_log日志是否有以下日志：

could not open file

具體排查與處理方案見以下鏈接：

https://bbs.huaweicloud.com/blogs/242269

5 實例重啟或主備切換

集群運行過程當中發現有：

FI監控頁面有主備斷連或者不同步告警:

編號

日志內容

1

Datanode主備不通過或者斷連，重要，xxxx

ps -ef 查看某一節點上gaussdb進程運行時間與其他實例不同

查看集群狀態不均衡需要分析主備切換原因。

若存在以上情況可按照以下步驟進行分析

使用root用戶查看/var/log/messages日志在實例重啟時間點是否有kill關鍵字，若存在則說明由于max_process_memory參數設置過大，將參數修改為適當值進行觀察，該參數計算方式詳細見產品文檔。

使用omm用戶（云上版本使用Ruby用戶）查看cm_agent日志（$GAUSSLOG/cm/cm_agent/cm_agent-xxx.log）在實例重啟時間點是否有kill關鍵字，若存在則說明dn hang或者cm_agent與cm_server連接異常，若該問題偶爾出現一次可不需做任何處理，若出現較為頻繁聯系華為工程師處理。

首先確認該集群是否配置操作系統core，若為配置請先配置操作系統core之后繼續觀察。core配置方案見以下鏈接：

若該集群已經配置core請檢查在對應目錄檢查是否有core文件產生，core文件產生路徑查看參考以下命令：

cat /proc/sys/kernel/core_pattern，該命令結果為絕對路徑直接在對應目錄查看，否則在對應重啟實例查看。

若產生core文件解析core文件將堆棧反饋給華為工程師進行處理。

若集群集群配置core集群實例多次重啟并且不屬于步驟一與步驟二的場景，請聯系華為工程師處理。

EI企業智能 Gauss AP 數據倉庫服務 GaussDB(DWS)

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

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