【巨杉數據庫SequoiaDB】巨杉Tech | 四步走，快速診斷數據庫集羣狀態

時間 2020-02-07

標籤巨杉數據庫SequoiaDB tech 快速診斷數據庫集羣狀態欄目 SQL 简体版

原文原文鏈接

1.背景node

SequoiaDB 巨杉數據庫是一款金融級分佈式數據庫，包括了分佈式 NewSQL、分佈式文件系統與對象存儲、與高性能 NoSQL 三種存儲模式，分別對應分佈式在線交易、非結構化數據和內容管理、以及海量數據管理和高性能訪問場景。數據庫

集羣通常會使用三副本方式以確保數據安全。倘若集羣發生因硬件故障等緣由致使的節點故障或集羣異常，數據庫管理員應進行系統的分析和診斷，以確保集羣正常工做，不會影響用戶的正常使用。本文將與你們分享一下基本的 SequoiaDB 數據庫診斷方法。數組

數據庫集羣診斷

1）肯定 SequoiaDB 的安裝路徑安全

若是用戶剛接觸全新的 SequoiaDB 環境，能夠經過 cat /etc/default/sequoiadb 命令查看數據庫安裝路徑。服務器

cat tc/default/sequoiadb 分佈式

NAME=sdbcmide

SDBADMIN_USER=sdbadmin性能

INSTALL_DIR=/opt/sequoiadbspa

INSTALL_DIR即 SequoiaDB 的安裝路徑。命令行

2）列出集羣節點信息

【檢查辦法】

切換到數據庫安裝用戶（默認爲sdbadmin用戶），查看節點信息和所有節點。

$ sdblist -l

$ sdblist -t all

從左到右依次爲SvcName（節點名稱）、Role（角色名稱分爲：編目節點、協調節點和數節點）、PID（進程號）、GID、NID、PRY（是否爲主節點）、GroupName（組名）、StartTime（啓動時間）、DBPath（安裝路徑）等信息，這些信息對於分析定位問題有很大的幫助。

【異常狀況】

檢查發現節點未啓動、節點啓動報錯和節點沒法啓動等問題。

【處理辦法】

假如數據節點11820節點未啓動首先應嘗試從新啓動該節點，使用 sdbstart -p 11820 命令從新啓動該節點。在節點安裝目錄下找到日誌信息，日誌信息爲 ${DBPath}/diaglog/ sdbdiag.log。

【案例分析】

執行 sdbstart -p 11820 啓動節點報錯。

$ sdbstart -p 11820

11820: 69 bytes out==>

db role: data_test error

Failed resolving arguments(error=-6), exit

<==

Error: Start [/opt/sequoiadb/bin/../conf/local/11820] failed, rc: 127(Invalid Argument)

Total: 1; Succeed: 0; Failed: 1

經過報錯信息 error 爲-6參數錯誤，且報出 ../conf/local/11820 配置信息錯誤，查詢節點的配置信息，節點的配置信息在安裝目錄下的 conf 目錄中。

$ vi /opt/sequoiadb/conf/local/11820/sdb.conf

svcname=11820

dbpath=/opt/sequoiadb/database/data/11820

logfilesz=64

weight=10

sortbuf=256

sharingbreak=180000

role=data_test

catalogaddr=sdb1:11803,sdb2:11803,sdb3:11803

對比正常的節點配置信息發現role角色名稱有誤，致使節點啓動失敗，修改正確後啓動成功。

3）檢查集羣節點是否正常

【檢查辦法】

在集羣環境下經過協調節點獲取數據庫快照，能夠經過監測 ErrNodes 判斷出是否存在節點不可用的狀況。

cd /opt/sequoiadb/bin/

$ sdb 'db = new Sdb("localhost",11810,"username","password")'

$ sdb 'db.snapshot(SDB_SNAP_DATABASE)'

{

"TotalNumConnects": 0,

"TotalDataRead": 787373,

"TotalIndexRead": 0,

……

"ErrNodes": [

{

  "NodeName": "sdb1:11820",

  "Flag": -129

},

{

  "NodeName": "sdb2:11820",

  "Flag": -129

}

]

}

Return 1 row(s).

Takes 0.27826s.

NodeName 是出故障節點的hostname與端口號，Flag 則是嘗試鏈接時所獲得的錯誤碼。在本例中，-129表明該節點處於全量同步狀態。

若是 ErrNodes 數組爲空，則意味着集羣中全部節點狀態正常：

$ sdb 'db.snapshot(SDB_SNAP_DATABASE)'

{

"TotalNumConnects": 1,

……

"ErrNodes": []

}

【異常狀況】

如上所示出現 -129 的錯誤信息，在 SequoiaDB 集羣中，因爲分佈式環境在運行過程當中，不可避免會遇到突發情況，例如：某個數據節點被管理員意外殺掉，機器忽然掉電重啓等，這些操做都有可能觸發SequoiaDB相關節點的全量同步狀態。

用戶能夠直連到問題數據節點，而後查看 SDB_SNAP_DATABASE 快照信息：

$ sdb 'data = new Sdb("sdb2",11820)'

$ sdb ' data.snapshot(SDB_SNAP_DATABASE)'

{

"NodeName": "sdb2:11820",

"HostName": "sdb2",

"ServiceName": "11820",

"GroupName": "dg1",

"IsPrimary": false,

"ServiceStatus": false,

"Status": "FullSync",

......

快照信息顯示此節點當前正在作全量同步，不能對外提供服務。

若是想知道某個數據節點過去是否進行過全量同步，能夠檢查此節點目錄下的 diaglog/sdbdiag.log 文件，看看是否有以下內容：

2019-11-08-21.38.26.332510 Level:EVENT

PID:3151 TID:3208

Function:_onAttach Line:217

File:SequoiaDB/engine/cls/clsReplSession.cpp

Message:

Session[Type:Sync-Dest,NodeID:1008,TID:1]: The db data is abnormal, need to synchronize full data

2019-11-08-21.38.26.333890 Level:EVENT

PID:3151 TID:3208

Function:_fullSync Line:722

File:SequoiaDB/engine/cls/clsReplSession.cpp

Message:

Session[Type:Sync-Dest,NodeID:1008,TID:1]: Start the synchronization of full

顯示結果代表此節點曾進行過全量同步。

【解決辦法】

等待全量同步自動完成，完成後節點會自動恢復；中止全量同步節點，拷貝主節點的數據文件到須要全量的節點中，而後從新啓動此節點便可。可是此方法須要業務無數據寫入，若是業務不能中止則須要等待節點自動進行全量同步。

SequoiaDB 的全量同步，實際上是節點在集羣環境中自動恢復的一種正常狀態。由於在X86服務平臺上運行，機器的穩定性遠遠沒有過去大小型機的問題，而且 SequoiaDB 的數據是存儲在本地 SATA 或者 SAS 磁盤中，若是機器忽然掉電，或者是節點忽然被強殺，那樣部分數據可能沒有真正寫入到磁盤中，節點就已經掛掉了。因此 SequoiaDB 爲了數據正確性，會在節點啓動時，去檢測該節點上次中止時是否按照正常流程中止，若是不是，則認爲當前存儲的數據是不可靠的，須要向相同數據組的其它節點請求同步全量的數據，以保證該節點的數據正確性。

logfilesz 默認爲64M，將 logfilesz 參數設置大一點可避免全量同步，建議設置爲1024M。

4）檢查集羣是否可用

【檢查辦法】

鏈接到 SequoiaDB 使用 insert 和 find 命令檢查集羣是否可用，若是集羣正常則可以正常返回。

$cd /opt/sequoiadb/bin/

$ sdb 'db = new Sdb("localhost",11810)'

$ sdb 'db.sample.employee.insert({"code":1,"name":"test1"})'

$ sdb 'db.sample.employee.find()'

$ sdb 'db.sample.employee.count()'

【異常狀況】

查詢 sample.employee 這個集合報錯-5。

$ sdb 'db.sample.employee. find ()'

sdb.js:505 uncaught exception: -5

File Exist

-5表示文件已經存在，打開協調節點所在的服務器，打開協調節點日誌文件並定位-5錯誤所發生的位置，查看到以下信息：

$ vi /opt/sequoiadb/database/coord/11810/diaglog/sdbdiag.log

2019-11-08-21.38.26.971524 Level:ERROR

PID:89651 TID:90037

Function:_queryOrDoOnCL Line:1076

File:SequoiaDB/engine/coord/coordQueryOperator.cpp

Message:

Query failed on node[{ GroupID:1000, NodeID:1002, ServiceID:2(SHARD) }], rc: -5

2019-11-08-21.38.26.971661 Level:ERROR

PID:89651 TID:90037

Function:execute Line:491

File:SequoiaDB/engine/coord/coordQueryOperator.cpp

Message:

Query failed, rc: -5

2019-11-08-21.38.26.971679 Level:ERROR

PID:89651 TID:90037

Function:_onQueryReqMsg Line:1850

File:SequoiaDB/engine/pmd/pmdProcessor.cpp

Message:

Execute operator[Query] failed, rc: -5

日誌中能夠看到，「Query failed on node[{ GroupID:1000, NodeID:1002, ServiceID:2(SHARD) }], rc: -5」錯誤信息表明着真正的錯誤來自數據節點：分區組1000，節點ID1000，ServiceID:2錯誤碼-5。接着在命令行使用 db.listReplicaGroups() 能夠獲得複製組信息：

$ sdb 'db.listReplicaGroups()'

{

……

{

  "HostName": "sdb3",

  "Status": 1,

  "dbpath": "/opt/sequoiadb/database/data/11820/",

  "Service": [

    {

      "Type": 0,

      "Name": "11820"

    },

    {

      "Type": 1,

      "Name": "11821"

    },

    {

      "Type": 2,

      "Name": "11822"

    }

  ],

  "NodeID": 1002

},

  ],

"GroupID": 1000,

"GroupName": "dg1",

"PrimaryNode": 1002,

"Role": 0,

"SecretID": 1969965962,

"Status": 1,

"Version": 7,

"_id": {