GaussDB T分布式集群數(shù)據(jù)庫每日維護(hù)必做必知

作者：魏斌 2020-02-22 14:14:24

數(shù)據(jù)庫

分布式 維護(hù)的目的是讓系統(tǒng)更穩(wěn)定，維護(hù)工作越簡(jiǎn)單，維護(hù)人員就越不容易出錯(cuò)。盡可能的把維護(hù)工作腳本化、工具化、自動(dòng)化，將人員解放出來做更有價(jià)值的事情是我們的目標(biāo)。路漫漫其修遠(yuǎn)兮，一起加油吧！

繼《GaussDB T分布式集群這樣安裝部署不踩坑》，我們開始GaussDB T每日維護(hù)必做的事情。新的一天從開啟主機(jī)開始，把虛擬機(jī)打開后發(fā)現(xiàn)上次安裝的數(shù)據(jù)庫沒有自啟動(dòng)，所有節(jié)點(diǎn)啟動(dòng)的相關(guān)進(jìn)程僅cm_agent進(jìn)程：

這個(gè)時(shí)候我們先要拉起ETCD：

OK，ETCD成功拉起，接下來我們拉起整個(gè)集群：

集群拉起成功。

后面我們會(huì)將ETCD及集群自動(dòng)拉起加入自啟動(dòng)，下面開始回到開篇的主題，每日維護(hù)開始。

一、集群狀態(tài)檢查

第一件事當(dāng)然是檢查集群各節(jié)點(diǎn)資源狀態(tài)情況啦，至于看啥，我們用一張圖來了解要點(diǎn)：

1、查看各節(jié)點(diǎn)資源是否是ON LINE，其中包括CM,CN,DN,ETCD等，如果不是，需進(jìn)一步核查原因了。

2、查看各節(jié)點(diǎn)對(duì)比昨日是否涉及節(jié)點(diǎn)切換情況，查看節(jié)點(diǎn)對(duì)應(yīng)的HOST即可。如有則異常，需進(jìn)一步核查原因了。

二、檢查主機(jī)資源使用情況(所有主機(jī))

1、主機(jī)目錄使用率

df -h

2、CPU、內(nèi)存及IO使用情況

這個(gè)檢查的方法很多，這里使用了vmstat,iostat,free，請(qǐng)重點(diǎn)關(guān)注以下紅框標(biāo)示的位置。

釋：id列代表的是CPU空閑率，free列代表的是空閑內(nèi)存，單位為頁。

釋：rMB/s及wMB/s的是每秒讀寫情況，%util在統(tǒng)計(jì)時(shí)間內(nèi)所有處理IO時(shí)間，除以總共統(tǒng)計(jì)時(shí)間。例如，如果統(tǒng)計(jì)間隔1秒，該設(shè)備有0.8秒在處理IO，而0.2秒閑置，那么該設(shè)備的%util = 0.8/1 = 80%，所以該參數(shù)暗示了設(shè)備的繁忙程度。如果該參數(shù)是100%表示設(shè)備已經(jīng)接近滿負(fù)荷運(yùn)行了(當(dāng)然如果是多磁盤，即使%util是100%，因?yàn)榇疟P的并發(fā)能力，所以磁盤使用未必就到了瓶頸)。

釋：重點(diǎn)關(guān)注free及available。

注：本節(jié)資源檢查需與基線進(jìn)行比對(duì)，如出入過大需進(jìn)一步核查原因。

三、核查各節(jié)點(diǎn)數(shù)據(jù)庫狀態(tài)

確認(rèn)CN及DN都處于open狀態(tài)，注意備DN是mount狀態(tài)。

四、表空間使用率檢查

當(dāng)在進(jìn)行使用率檢查之前，先說下表空間如何創(chuàng)建。

1、連接到cn

zsql omm/[email protected]:8000 –q

2、創(chuàng)建表空間

CREATE TABLESPACE tbs_test1 DATAFILE 'tbs_test1' size 100m SHARD;

注：創(chuàng)建表空間時(shí)，使用SHARD關(guān)鍵字則支持將創(chuàng)建表空間語句自動(dòng)下發(fā)至CN和DN節(jié)點(diǎn)且僅支持使用相對(duì)路徑;若不使用SHARD關(guān)鍵字，則可使用絕對(duì)路徑，同時(shí)需要在所有CN和主DN節(jié)點(diǎn)上都創(chuàng)建這個(gè)表空間后，才能正常在這個(gè)表空間下創(chuàng)建表。

3、檢查數(shù)據(jù)文件，我們會(huì)發(fā)現(xiàn)在CN及DN都創(chuàng)建了對(duì)應(yīng)的表空間及數(shù)據(jù)文件

注：連接主DN使用如下命令連接。

zsql / as sysdba -D /gaussdb/data/data_dn1 -q

4、檢查表空間的使用率

  
 
 
 

   
  
  
  
set line 300 
   
  
  
  
set pages 2000 
   
  
  
  
set timing off 
   
  
  
  
col tablespace_name for a25 
   
  
  
  
col sum_GB for a15 
   
  
  
  
col free_GB for a15 
   
  
  
  
col use_precent for a15 
   
  
  
  
select b.tablespace_name, 
   
  
  
  
       round(sum(b.bytes) / 1024 / 1024 / 1024, 0) sum_GB, 
   
  
  
  
       round(sum(nvl(a.bytes, 0)) / 1024 / 1024 / 1024, 0) free_GB, 
   
  
  
  
       round((sum(b.bytes) - sum(nvl(a.bytes, 0))) / sum(b.bytes), 4) * 100 use_precent, 
   
  
  
  
       count(*) 
   
  
  
  
  from (select tablespace_name, file_id, sum(bytes) bytes 
   
  
  
  
          from adm_free_space 
   
  
  
  
         group by tablespace_name, file_id) a, 
   
  
  
  
       adm_data_files b 
   
  
  
  
 where a.file_id(+) = b.file_id 
   
  
  
  
   and a.tablespace_name(+) = b.tablespace_name 
   
  
  
  
 group by b.tablespace_name 
   
  
  
  
having round((sum(b.bytes) - sum(nvl(a.bytes, 0))) / sum(b.bytes), 4) * 100 >= 0 
   
  
  
  
 order by 4 desc; 
  
 
 
 

注：表空間使用率檢查需在所有的主CN及主DN運(yùn)行。

五、異常等待事件檢查

col event form a38

select event,count(*) from DV_SESSIONS where LOCK_WAIT = 'Y' group by event order by 2 desc;

注：在所有主DN核查是否存在異常等待事件。

如圖所示存在TX等待，我們可以通過以下SQL查看下鎖源在干啥：

  
 
 
 

   
  
  
  
select SID,SERIAL#,USERNAME,CURR_SCHEMA,CLIENT_IP,CLIENT_PORT,OSUSER,MACHINE,PROGRAM, 
   
  
  
  
STATUS,LOCK_WAIT,EVENT,MODULE,CURRENT_SQL from dv_sessions 
   
  
  
  
where sid in (select WAIT_SID from v$session where event like '%TX%'); 
  
 
 
 

如發(fā)現(xiàn)會(huì)話狀態(tài)是非活動(dòng)且是應(yīng)用程序連上來的，可以聯(lián)系應(yīng)用核查是否正常，如可以kill我們可以運(yùn)行ALTER SYSTEM KILL SESSION 'SID,SERIAL#'; 殺會(huì)話。

六、日志檢查

在數(shù)據(jù)庫運(yùn)行過程中，會(huì)產(chǎn)生大量用于數(shù)據(jù)庫日常維護(hù)的運(yùn)行、審計(jì)、 DEBUG、告警等日志。在數(shù)據(jù)庫發(fā)生故障時(shí)，可以使用這些日志進(jìn)行問題定位和數(shù)據(jù)庫恢復(fù)的操作。

下面就常用的日志類型做下簡(jiǎn)介：

1、運(yùn)行日志

打印GaussDB T數(shù)據(jù)庫運(yùn)行信息，如果數(shù)據(jù)庫出現(xiàn)故障，請(qǐng)查看zengine.rlog。

日志目錄：默認(rèn)為“ $GSDB_DATA/log/run/zengine.rlog”或參數(shù)log_home對(duì)應(yīng)的路徑run子目錄下，如果想修改其路徑重啟生效。

CN節(jié)點(diǎn)：

DN節(jié)點(diǎn)：

查看運(yùn)行日志如下：

2、慢查詢?nèi)罩?/p>

打印GaussDB 100數(shù)據(jù)庫執(zhí)行時(shí)間超過閾值(由LONGSQL_TIMEOUT參數(shù)控制)的SQL信息到zengine.lsql日志文件中。

日志目錄：默認(rèn)為“ $GSDB_DATA/log/longsql/zengine.lsql”。

3、告警日志

打印GaussDB 100數(shù)據(jù)庫運(yùn)行告警信息。如需了解告警信息，請(qǐng)查看zenith_alarm.log。

日志目錄：“ $GSDB_DATA/log/zenith_alarm.log”。

4、操作日志

記錄用戶通過ZSQL工具對(duì)GaussDB 100數(shù)據(jù)庫的操作信息。如果需要了解操作記錄，請(qǐng)查看zsql.olog。

日志目錄：“ $GSDB_DATA/log/oper/zsql.olog”。

5、TRACE日志

記錄數(shù)據(jù)庫會(huì)話死鎖的信息。如需查看會(huì)話死鎖信息，請(qǐng)查看zengine_00003_xxxxxx.trc。

日志目錄：“ $GSDB_DATA/trc/zengine_00003_xxxxxx.trc”。

常見錯(cuò)誤碼：

GS-00716：Found %s deadlock in session (%u)

錯(cuò)誤原因：不同會(huì)話中并發(fā)交叉操作了同一批數(shù)據(jù)，造成死鎖。

解決辦法：

• 查看trace log 或者 run log (根據(jù)數(shù)據(jù)庫版本不同，死鎖日志位置不同);
• 根據(jù)日志里記錄的具體信息，包括死鎖類型，SQL語句等，排查業(yè)務(wù)語句。

GS-00715：The snapshot was outdated.

錯(cuò)誤原因：快照過舊。

解決辦法：

• 重新運(yùn)行SQL;
• 將長(zhǎng)時(shí)間運(yùn)行的高耗SQL優(yōu)化或拆分。

GS-00713：No free undo page

錯(cuò)誤原因：UNDO表空間不足。

解決辦法：

• 增大UNDO表空間大小;
• 將大事務(wù)kill釋放UNDO。

GS-00305：%s timeout

錯(cuò)誤原因：網(wǎng)絡(luò)api超時(shí)。

解決辦法：

• 請(qǐng)確保主機(jī)網(wǎng)絡(luò)正常。

GS-00774：Failover in progress, can not be connected

錯(cuò)誤原因：備機(jī)正在做failover時(shí)，主機(jī)的日志發(fā)送線程來連接備機(jī)。

解決辦法：

• 將主機(jī)停止掉，待備機(jī)升主后，將原主降備。

GS-00839：Flush redo file:%s, offset:%u, size:%lu failed

錯(cuò)誤原因：寫redo日志文件的時(shí)候失敗了，一般是文件系統(tǒng)或者磁盤有問題。

解決辦法：

• 檢查操作系統(tǒng)或磁盤。

GaussDB T數(shù)據(jù)庫維護(hù)的工作很多，除了以上每日必做的事情之外，還有會(huì)話連接失敗、緩沖區(qū)刷盤失敗、CN/DN節(jié)點(diǎn)狀態(tài)異常、CM Server節(jié)點(diǎn)狀態(tài)異常、主備DN節(jié)點(diǎn)日志同步延遲過大等等問題核查。其中很多我們可以通過使用Database Manager分析處理告警或者使用自己開發(fā)腳本實(shí)現(xiàn)告警。

維護(hù)的目的是讓系統(tǒng)更穩(wěn)定，維護(hù)工作越簡(jiǎn)單，維護(hù)人員就越不容易出錯(cuò)。盡可能的把維護(hù)工作腳本化、工具化、自動(dòng)化，將人員解放出來做更有價(jià)值的事情是我們的目標(biāo)。路漫漫其修遠(yuǎn)兮，一起加油吧!

新聞名稱：GaussDBT分布式集群數(shù)據(jù)庫每日維護(hù)必做必知
文章位置：http://m.fisionsoft.com.cn/article/dpcjdpe.html