Categories
程式開發

GaussDB T分佈式集群數據庫每日維護必做必知


本文由 dbaplus 社群授權轉載。

《GaussDB T分佈式集群這樣安裝部署不踩坑》,我們開始GaussDB T每日維護必做的事情。新的一天從開啟主機開始,把虛擬機打開後發現上次安裝的數據庫沒有自啟動,所有節點啟動的相關進程僅cm_agent進程:

GaussDB T分佈式集群數據庫每日維護必做必知 1

這個時候我們先要拉起ETCD:

GaussDB T分佈式集群數據庫每日維護必做必知 2

OK,ETCD成功拉起,接下來我們拉起整個集群:

GaussDB T分佈式集群數據庫每日維護必做必知 3

集群拉起成功。

後面我們會將ETCD及集群自動拉起加入自啟動,下面開始回到開篇的主題,每日維護開始。

一、集群狀態檢查

第一件事當然是檢查集群各節點資源狀態情況啦,至於看啥,我們用一張圖來了解要點:

GaussDB T分佈式集群數據庫每日維護必做必知 4

GaussDB T分佈式集群數據庫每日維護必做必知 5

1、查看各節點資源是否是ON LINE,其中包括CM,CN,DN,ETCD等,如果不是,需進一步核查原因了。

2、查看各節點對比昨日是否涉及節點切換情況,查看節點對應的HOST即可。如有則異常,需進一步核查原因了。

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

1、主機目錄使用率

df -h

GaussDB T分佈式集群數據庫每日維護必做必知 6

2、CPU、內存及IO使用情況

這個檢查的方法很多,這裡使用了vmstat,iostat,free,請重點關注以下紅框標示的位置。

GaussDB T分佈式集群數據庫每日維護必做必知 7

釋:id列代表的是CPU空閒率,free列代表的是空閒內存,單位為頁。

GaussDB T分佈式集群數據庫每日維護必做必知 8

釋:rMB/s及wMB/s的是每秒讀寫情況,%util在統計時間內所有處理IO時間,除以總共統計時間。例如,如果統計間隔1秒,該設備有0.8秒在處理IO,而0.2秒閒置,那麼該設備的%util = 0.8/1 = 80%,所以該參數暗示了設備的繁忙程度。如果該參數是100%表示設備已經接近滿負荷運行了(當然如果是多磁盤,即使%util是100%,因為磁盤的並發能力,所以磁盤使用未必就到了瓶頸)。

GaussDB T分佈式集群數據庫每日維護必做必知 9

釋:重點關注free及available。

注:本節資源檢查需與基線進行比對,如出入過大需進一步核查原因。

三、核查各節點數據庫狀態

GaussDB T分佈式集群數據庫每日維護必做必知 10

GaussDB T分佈式集群數據庫每日維護必做必知 11

確認CN及DN都處於open狀態,注意備DN是mount狀態。

四、表空間使用率檢查

當在進行使用率檢查之前,先說下表空間如何創建。

1、連接到cn

zsql omm/[email protected]:8000 –q

GaussDB T分佈式集群數據庫每日維護必做必知 12

2、創建表空間

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

GaussDB T分佈式集群數據庫每日維護必做必知 13

注:創建表空間時,使用SHARD關鍵字則支持將創建表空間語句自動下發至CN和DN節點且僅支持使用相對路徑;若不使用SHARD關鍵字,則可使用絕對路徑,同時需要在所有CN和主DN節點上都創建這個表空間後,才能正常在這個表空間下創建表。

3、檢查數據文件,我們會發現在CN及DN都創建了對應的表空間及數據文件

GaussDB T分佈式集群數據庫每日維護必做必知 14

GaussDB T分佈式集群數據庫每日維護必做必知 15

GaussDB T分佈式集群數據庫每日維護必做必知 16

注:連接主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;

GaussDB T分佈式集群數據庫每日維護必做必知 17

注:表空間使用率檢查需在所有的主CN及主DN運行。

五、異常等待事件檢查

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

GaussDB T分佈式集群數據庫每日維護必做必知 18

注:在所有主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#’; 殺會話。

GaussDB T分佈式集群數據庫每日維護必做必知 19

六、日誌檢查

在數據庫運行過程中,會產生大量用於數據庫日常維護的運行、審計、 DEBUG、告警等日誌。在數據庫發生故障時,可以使用這些日誌進行問題定位和數據庫恢復的操作。

下面就常用的日誌類型做下簡介:

1、運行日誌

打印GaussDB T數據庫運行信息,如果數據庫出現故障,請查看zengine.rlog。

日誌目錄:默認為“ $GSDB_DATA/log/run/zengine.rlog”或參數log_home對應的路徑run子目錄下,如果想修改其路徑重啟生效。

CN節點:

GaussDB T分佈式集群數據庫每日維護必做必知 20

DN節點:

GaussDB T分佈式集群數據庫每日維護必做必知 21

查看運行日誌如下:

GaussDB T分佈式集群數據庫每日維護必做必知 22

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分析處理告警或者使用自己開發腳本實現告警。

維護的目的是讓系統更穩定,維護工作越簡單,維護人員就越不容易出錯。盡可能的把維護工作腳本化、工具化、自動化,將人員解放出來做更有價值的事情是我們的目標。路漫漫其修遠兮,一起加油吧!

作者介紹

魏斌,新炬網絡資深數據庫專家,長期服務於運營商、金融、製造業及政企客戶。從傳統商業DB到開源分佈式,均有涉獵及獨到見解。職業以來紮根客戶一線,對於緊急故障處置及性能問題優化具有豐富經驗,尤善於災備、多中心建設及異構數據遷移。

原文鏈接

https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650785531&idx=1&sn=ba316936bb1b40681a5bf0caf9745fb2&chksm=f3f9736ec48efa78efe0cdf0b4f6cc26bae4bf98e163beb46b8c1e773d1aee0fca8fad47cfc5&scene=27#wechat_redirect