共計 3851 個字符，預計需要花費 10 分鐘才能閱讀完成。

這期內容當中丸趣 TV 小編將會給大家帶來有關 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 ndash;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 分析處理告警或者使用自己開發腳本實現告警。

維護的目的是讓系統更穩定，維護工作越簡單，維護人員就越不容易出錯。

上述就是丸趣 TV 小編為大家分享的 GaussDB T 分布式集群數據庫的維護工作有哪些了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注丸趣 TV 行業資訊頻道。