【巨杉數據庫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

從左到右依次為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集群診斷基本方法，幫助用戶系統地分析和診斷集群出現的問題并盡快解決。