【巨杉数据库SequoiaDB】巨杉Tech | 四步走，快速诊断数据库集群状态

时间  2020-02-07
标签 巨杉数据库SequoiaDB tech 快速 诊断 数据库 集群 状态 栏目 SQL 繁體版
原文   原文链接

1.背景node

SequoiaDB 巨杉数据库是一款金融级分布式数据库，包括了分布式 NewSQL、分布式文件系统与对象存储、与高性能 NoSQL 三种存储模式，分别对应分布式在线交易、非结构化数据和内容管理、以及海量数据管理和高性能访问场景。数据库

集群通常会使用三副本方式以确保数据安全。倘若集群发生因硬件故障等缘由致使的节点故障或集群异常，数据库管理员应进行系统的分析和诊断，以确保集群正常工做，不会影响用户的正常使用。本文将与你们分享一下基本的 SequoiaDB 数据库诊断方法。数组

  1. 数据库集群诊断

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": {

"$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集群诊断基本方法，帮助用户系统地分析和诊断集群出现的问题并尽快解决。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程