【巨杉資料庫SequoiaDB】巨杉Tech | 四步走，快速診斷資料庫叢集狀態

1.背景

SequoiaDB 巨杉資料庫是一款金融級分散式資料庫，包括了分散式 NewSQL、分散式檔案系統與物件儲存、與高效能 NoSQL 三種儲存模式，分別對應分散式線上交易、非結構化資料和內容管理、以及海量資料管理和高效能訪問場景。

叢集一般會使用三副本方式以確保資料安全。假若叢集發生因硬體故障等原因導致的節點故障或叢集異常，資料庫管理員應進行系統的分析和診斷，以確保叢集正常工作，不會影響使用者的正常使用。本文將與大家分享一下基本的 SequoiaDB 資料庫診斷方法。

2. 資料庫叢集診斷

1）確定 SequoiaDB 的安裝路徑

如果使用者剛接觸全新的 SequoiaDB 環境，可以通過 cat /etc/default/sequoiadb 命令檢視資料庫安裝路徑。

# cat tc/default/sequoiadb

NAME=sdbcm

SDBADMIN_USER=sdbadmin

INSTALL_DIR=/opt/sequoiadb

INSTALL_DIR即 SequoiaDB 的安裝路徑。

2）列出叢集節點資訊

【檢查辦法】

切換到資料庫安裝使用者（預設為sdbadmin使用者），檢視節點資訊和全部節點。

$ sdblist -l

$ sdblist -t all

【巨杉資料庫SequoiaDB】巨杉Tech | 四步走，快速診斷資料庫叢集狀態

從左到右依次為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": {

"$oid": "5d843fd23e28e361958a76bc"

}

通過遍歷分割槽組資訊，可以發現組ID1000，節點ID1002所對應的機器為sdb3的11820這個節點，資料庫路徑為 /opt/sequoiadb/database/data/11820，檢視節點日誌：

vi /opt/sequoiadb/database/data/11820/diaglog/sdbdiag.log

2019-11-08-21.38.26.584673 Level:ERROR

PID:4347 TID:4370

Function:open Line:66

File:SequoiaDB/engine/oss/ossMmap.cpp

Message:

Failed to open file, rc: -5

2019-11-08-21.38.26.584698 Level:ERROR

PID:4347 TID:4370

Function:openStorage Line:700

File:SequoiaDB/engine/dms/dmsStorageBase.cpp

Message:

Failed to open /opt/sequoiadb/database/data/11820/sample.1.data, rc=-5

2019-11-08-21.38.26.584721 Level:ERROR

PID:4347 TID:4370

Function:open Line:1172

File:SequoiaDB/engine/dms/dmsStorageUnit.cpp

Message:

Open storage data su failed, rc: -5

2019-11-08-21.38.26.584756 Level:ERROR

PID:4347 TID:4370

Function:rtnCreateCollectionSpaceCommand Line:1160

File:SequoiaDB/engine/rtn/rtnCommandImpl.cpp

Message:

Failed to create collection space sample at /opt/sequoiadb/database/data/11820/, rc: -5

通過日誌檔案可以發現-5的錯誤不存在的錯誤，是因為sdb3機器中的11820節點下的sample.1.data 檔案存在異常。因此接下來進入資料節點所在路徑檢查集合空間檔案，發現 sample 這個集合檔案已經被損壞。

[sdbadmin@sdb3 11820]$ ll

total 1233564

drwxrwxrwx. 2 sdbadmin sdbadmin_group 4096 Sep 19 19:56 archivelog

drwxrwxrwx. 2 sdbadmin sdbadmin_group 4096 Sep 19 19:56 bakfile

drwxrwxrwx. 2 sdbadmin sdbadmin_group 4096 Nov 8 06:11 diaglog

-rw-r-----. 1 sdbadmin sdbadmin_group 0 Nov 8 05:27 sample.1.data

-rw-r-----. 1 sdbadmin sdbadmin_group 0 Nov 8 05:27 sample.1.idx

……

drwxrwxrwx. 2 sdbadmin sdbadmin_group 4096 Sep 19 19:56 tmp

將其他機器的 sample.1.data 和 sample.1.idx 這兩個檔案拷貝到 sdb3 的11820中：

$ scp -r sdbadmin@sdb2:/opt/sequoiadb/database/data/11820/sample.1.* .

$ sdb 'var dg = db.getRG("dg1")'

$ sdb 'dg.stop()'

$ sdb 'dg.start()'

重新查詢集合正常：

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

{

"_id": {

"$oid": "5dc5755ec73f4486ee4efe40"

},

"a": 1

}

Return 1 row(s)

3.總結

本文介紹了巨杉資料庫SequoiaDB叢集診斷基本方法，幫助使用者系統地分析和診斷叢集出現的問題並儘快解決。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31534344/viewspace-2666890/，如需轉載，請註明出處，否則將追究法律責任。

【巨杉資料庫SequoiaDB】巨杉Tech | 四步走，快速診斷資料庫叢集狀態

相關文章