GaussDB T分布式集群數據庫每日維護必做必知
繼《GaussDB T分布式集群這樣安裝部署不踩坑》，我們開始GaussDB T每日維護必做的事情。新的一天從開啟主機開始，把虛擬機打開后發現上次安裝的數據庫沒有自啟動，所有節點啟動的相關進程僅cm_agent進程：
這個時候我們先要拉起ETCD：
OK，ETCD成功拉起，接下來我們拉起整個集群：
集群拉起成功。
后面我們會將ETCD及集群自動拉起加入自啟動，下面開始回到開篇的主題，每日維護開始。
一、集群狀態檢查
第一件事當然是檢查集群各節點資源狀態情況啦，至于看啥，我們用一張圖來了解要點：
1、查看各節點資源是否是ON LINE，其中包括CM,CN,DN,ETCD等，如果不是，需進一步核查原因了。
2、查看各節點對比昨日是否涉及節點切換情況，查看節點對應的HOST即可。如有則異常，需進一步核查原因了。
二、檢查主機資源使用情況(所有主機)
1、主機目錄使用率
df -h
2、CPU、內存及IO使用情況
這個檢查的方法很多，這里使用了vmstat,iostat,free，請重點關注以下紅框標示的位置。
釋：id列代表的是CPU空閑率，free列代表的是空閑內存，單位為頁。
釋：rMB/s及wMB/s的是每秒讀寫情況，%util在統計時間內所有處理IO時間，除以總共統計時間。例如，如果統計間隔1秒，該設備有0.8秒在處理IO，而0.2秒閑置，那么該設備的%util = 0.8/1 = 80%，所以該參數暗示了設備的繁忙程度。如果該參數是100%表示設備已經接近滿負荷運行了(當然如果是多磁盤，即使%util是100%，因為磁盤的并發能力，所以磁盤使用未必就到了瓶頸)。
釋：重點關注free及available。
注：本節資源檢查需與基線進行比對，如出入過大需進一步核查原因。
三、核查各節點數據庫狀態
確認CN及DN都處于open狀態，注意備DN是mount狀態。
四、表空間使用率檢查
當在進行使用率檢查之前，先說下表空間如何創建。
1、連接到cn
zsql omm/gaussdb_123@127.0.0.1:8000 –q
2、創建表空間
CREATE TABLESPACE tbs_test1 DATAFILE 'tbs_test1' size 100m SHARD;
注：創建表空間時，使用SHARD關鍵字則支持將創建表空間語句自動下發至CN和DN節點且僅支持使用相對路徑;若不使用SHARD關鍵字，則可使用絕對路徑，同時需要在所有CN和主DN節點上都創建這個表空間后，才能正常在這個表空間下創建表。
3、檢查數據文件，我們會發現在CN及DN都創建了對應的表空間及數據文件
注：連接主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運行。
五、異常等待事件檢查
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%');
如發現會話狀態是非活動且是應用程序連上來的，可以聯系應用核查是否正常，如可以kill我們可以運行ALTER SYSTEM KILL SESSION 'SID,SERIAL#'; 殺會話。
六、日志檢查
在數據庫運行過程中，會產生大量用于數據庫日常維護的運行、審計、 DEBUG、告警等日志。在數據庫發生故障時，可以使用這些日志進行問題定位和數據庫恢復的操作。
下面就常用的日志類型做下簡介：
1、運行日志
打印GaussDB T數據庫運行信息，如果數據庫出現故障，請查看zengine.rlog。
日志目錄：默認為“ $GSDB_DATA/log/run/zengine.rlog”或參數log_home對應的路徑run子目錄下，如果想修改其路徑重啟生效。
CN節點：
DN節點：
查看運行日志如下：
2、慢查詢日志
打印GaussDB 100數據庫執行時間超過閾值(由LONGSQL_TIMEOUT參數控制)的SQL信息到zengine.lsql日志文件中。
日志目錄：默認為“ $GSDB_DATA/log/longsql/zengine.lsql”。
3、告警日志
打印GaussDB 100數據庫運行告警信息。如需了解告警信息，請查看zenith_alarm.log。
日志目錄：“ $GSDB_DATA/log/zenith_alarm.log”。
4、操作日志
記錄用戶通過ZSQL工具對GaussDB 100數據庫的操作信息。如果需要了解操作記錄，請查看zsql.olog。
日志目錄：“ $GSDB_DATA/log/oper/zsql.olog”。
5、TRACE日志
記錄數據庫會話死鎖的信息。如需查看會話死鎖信息，請查看zengine_00003_xxxxxx.trc。
日志目錄：“ $GSDB_DATA/trc/zengine_00003_xxxxxx.trc”。
常見錯誤碼：
GS-00716：Found %s deadlock in session (%u)
錯誤原因：不同會話中并發交叉操作了同一批數據，造成死鎖。
解決辦法：
- 查看trace log 或者 run log (根據數據庫版本不同，死鎖日志位置不同);
- 根據日志里記錄的具體信息，包括死鎖類型，SQL語句等，排查業務語句。
GS-00715：The snapshot was outdated.
錯誤原因：快照過舊。
解決辦法：
- 重新運行SQL;
- 將長時間運行的高耗SQL優化或拆分。
GS-00713：No free undo page
錯誤原因：UNDO表空間不足。
解決辦法：
- 增大UNDO表空間大小;
- 將大事務kill釋放UNDO。
GS-00305：%s timeout
錯誤原因：網絡api超時。
解決辦法：
- 請確保主機網絡正常。
GS-00774：Failover in progress, can not be connected
錯誤原因：備機正在做failover時，主機的日志發送線程來連接備機。
解決辦法：
- 將主機停止掉，待備機升主后，將原主降備。
GS-00839：Flush redo file:%s, offset:%u, size:%lu failed
錯誤原因：寫redo日志文件的時候失敗了，一般是文件系統或者磁盤有問題。
解決辦法：
- 檢查操作系統或磁盤。
GaussDB T數據庫維護的工作很多，除了以上每日必做的事情之外，還有會話連接失敗、緩沖區刷盤失敗、CN/DN節點狀態異常、CM Server節點狀態異常、主備DN節點日志同步延遲過大等等問題核查。其中很多我們可以通過使用Database Manager分析處理告警或者使用自己開發腳本實現告警。
維護的目的是讓系統更穩定，維護工作越簡單，維護人員就越不容易出錯。盡可能的把維護工作腳本化、工具化、自動化，將人員解放出來做更有價值的事情是我們的目標。路漫漫其修遠兮，一起加油吧!
