巨杉Tech | 四步走,快速诊断数据库集群状态

Posted 巨杉数据库

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了巨杉Tech | 四步走,快速诊断数据库集群状态相关的知识,希望对你有一定的参考价值。


1.背景


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


集群一般会使用三副本方式以确保数据安全。假若集群发生因硬件故障等原因导致的节点故障或集群异常,数据库管理员应进行系统的分析和诊断,以确保集群正常工作,不会影响用户的正常使用。本文将与大家分享一下基本的 SequoiaDB 数据库诊断方法。



2. 数据库集群诊断


1)确定 SequoiaDB 的安装路

如果用户刚接触全新的 SequoiaDB 环境,可以通过 cat /etc/default/sequoiadb 命令查看数据库安装路
# cat /etc/default/sequoiadb NAME=sdbcmSDBADMIN_USER=sdbadminINSTALL_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 errorFailed 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=11820dbpath=/opt/sequoiadb/database/data/11820logfilesz=64weight=10sortbuf=256sharingbreak=180000role=data_testcatalogaddr=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:EVENTPID:3151 TID:3208Function:_onAttach Line:217File:SequoiaDB/engine/cls/clsReplSession.cppMessage:Session[Type:Sync-Dest,NodeID:1008,TID:1]: The db data is abnormal, need to synchronize full data2019-11-08-21.38.26.333890 Level:EVENTPID:3151 TID:3208Function:_fullSync Line:722File:SequoiaDB/engine/cls/clsReplSession.cppMessage: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: -5File Exist
-5表示文件已经存在,打开协调节点所在的服务器,打开协调节点日志文件并定位-5错误所发生的位置,查看到如下信息:
$ vi /opt/sequoiadb/database/coord/11810/diaglog/sdbdiag.log2019-11-08-21.38.26.971524 Level:ERRORPID:89651 TID:90037Function:_queryOrDoOnCL Line:1076File:SequoiaDB/engine/coord/coordQueryOperator.cppMessage:Query failed on node[{ GroupID:1000, NodeID:1002, ServiceID:2(SHARD) }], rc: -5
2019-11-08-21.38.26.971661 Level:ERRORPID:89651 TID:90037Function:execute Line:491File:SequoiaDB/engine/coord/coordQueryOperator.cppMessage:Query failed, rc: -5
2019-11-08-21.38.26.971679 Level:ERRORPID:89651 TID:90037Function:_onQueryReqMsg Line:1850File:SequoiaDB/engine/pmd/pmdProcessor.cppMessage: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.log2019-11-08-21.38.26.584673 Level:ERRORPID:4347 TID:4370Function:open Line:66File:SequoiaDB/engine/oss/ossMmap.cppMessage:Failed to open file, rc: -5
2019-11-08-21.38.26.584698 Level:ERRORPID:4347 TID:4370Function:openStorage Line:700File:SequoiaDB/engine/dms/dmsStorageBase.cppMessage:Failed to open /opt/sequoiadb/database/data/11820/sample.1.data, rc=-5
2019-11-08-21.38.26.584721 Level:ERRORPID:4347 TID:4370Function:open Line:1172File:SequoiaDB/engine/dms/dmsStorageUnit.cppMessage:Open storage data su failed, rc: -5
2019-11-08-21.38.26.584756 Level:ERRORPID:4347 TID:4370Function:rtnCreateCollectionSpaceCommand Line:1160File:SequoiaDB/engine/rtn/rtnCommandImpl.cppMessage:Failed to create collection space sample at /opt/sequoiadb/database/data/11820/, rc: -5
通过日志文件可以发现-5的错误不存在的错误,是因为sdb3机器中的11820节点下的sample.1.data 文件存在异常。因此接下来进入数据节点所在路径检查集合空间文件,发现 sample 这个集合文件已经被损坏。
[sdbadmin@sdb3 11820]$ lltotal 1233564drwxrwxrwx. 2 sdbadmin sdbadmin_group 4096 Sep 19 19:56 archivelogdrwxrwxrwx. 2 sdbadmin sdbadmin_group 4096 Sep 19 19:56 bakfiledrwxrwxrwx. 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集群诊断基本方法,帮助用户系统地分析和诊断集群出现的问题并尽快解决。


往期技术干货





点击阅读原文,获取更多精彩内容~

以上是关于巨杉Tech | 四步走,快速诊断数据库集群状态的主要内容,如果未能解决你的问题,请参考以下文章

巨杉数据库SequoiaDB巨杉 Tech | 几分钟实现巨杉数据库容器化部署

巨杉Tech | SequoiaDB高可用原理详解

Tomcat学习四步走:内核集群参数及性能

巨杉数据库SequoiaDB巨杉Tech | 巨杉数据库的并发 malloc 实现

巨杉数据库SequoiaDB巨杉Tech |巨杉数据库的HTAP场景实践

巨杉Tech | 读写分离机制与实践