1.背景
SequoiaDB 巨杉數據庫是一款金融級分佈式數據庫，包括了分佈式 NewSQL、分佈式文件系統與對象存儲、與高性能 NoSQL 三種存儲模式，分別對應分佈式在線交易、非結構化數據和內容管理、以及海量數據管理和高性能訪問場景。
集羣一般會使用三副本方式以確保數據安全。假若集羣發生因硬件故障等原因導致的節點故障或集羣異常，數據庫管理員應進行系統的分析和診斷，以確保集羣正常工作，不會影響用戶的正常使用。本文將與大家分享一下基本的 SequoiaDB 數據庫診斷方法。
- 數據庫集羣診斷
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集羣診斷基本方法，幫助用戶系統地分析和診斷集羣出現的問題並儘快解決。