星环大数据基础平台 TDH
星环数据云平台 TDC
分布式数据库 ArgoDB
分布式交易型数据库 KunDB
星环大数据开发工具 TDS
智能分析工具 Sophon
星环知识平台 Transwarp Knowledge Hub
星环大模型一体机
星环智能识别一体机
星环国产ARM大数据一体机
星环X86超融合大数据一体机
DDL报错
建表失败
arm环境，华为鲲鹏，网络丢包，出现cause:CreateTablet, code:RpcTimeout, msg:Deadline Exceeded, cost:10000475us，报错原因是Tabletserver数量不符合预期，检查安装部署文档
表变更超时
如果drop table或partition变更出现超时，如下图所示：
当出现上面的schema变更无法完成的情况时，需要确认以下几点：
-
是否重启过master
master的重启，可能会带来master group的leadership切换。目前如果leadership切换，会造成有一段时间（默认是10min）无法进行schema变更。只读事务只维护在master leader的内存中并且没有进行持久化. 切换leader后, 新的leader需要通过心跳来获取只读事务的信息
-
如果有事务对目标表有读或写的依赖，那么schema变更的进度就会被延后
curl -XGET "<host>:<port>//bulk_transaction?pretty"
例如下图
上图可以看到，有一个读写事务（存在于bulktransactiondescriptions中）和一个只读事务（存在于bulkrotransactiondescriptions中）,id为218的读写事务，状态是active，并且正在对id为65的表进行bulk写入,只读事务正在读id为65的表,如果上面的两个事务，长时间没有结束。会造成id为65的表的schema变更无法结束。
表写入异常
holo表bulk事务begin报错
-
现象
过多的活跃事务 too many uncommitted bulk transactions, current:5000, max:5000
-
排查命令
事务停留在active状态
curl -XGET "ip:port/bulktransaction?pretty&status=active"
事务停留在precommitting
curl -XGET"ip:port/bulktransaction?pretty&status=precommitting"
事务停留在committing状态
curl -XGET "ip:port/bulktransaction?pretty&status=committing"
holo表bulk事务precommit阶段报错
-
现象
bulk read response size over limit, max:26843545, current:26847025
rowset number over limit
-
排查命令
sql长时间无法结束，导致多版本无法合并
compact任务不及时
holo engine副本之间数据不一致
表查询异常
Executor报文件不存在
Shiva使用的数据目录错误地挂载到根分区
如何判断数据盘错误地挂载到根分区上
排查和定位的方法参考此文档 Manager诊断树——挂载链断裂问题排查方案。
如果tabletserver的数据盘挂载到了根分区
A. 确保tabletserver的数据盘挂载到了正确的分区。
B. 停止挂载出现问题的tabletserver角色。
C. 在TDH Manager上，对Shiva服务进行配置服务。
D. 检查/proc/mounts中对应磁盘，确保挂载到了正确的数据盘上。
E. 如果物理节点的数据盘上有数据，说明tabletserver角色是在正常安装并工作一段时间后数据盘被错误挂载到了根分区。此时需要清空或重建数据目录，清除原有的残留数据。
F. 启动出现问题的tabletserver角色。这是tabletserver会使用正确的数据盘。
G. 等待tabletserver启动完成后，shiva会自动恢复丢失的副本。
如果master的数据盘挂载到了根分区
A. 将有问题的master角色从集群中剔除。
B. 确保master使用的数据目录是正确挂载的。
C. 通过新增master角色流程重新将master角色加回集群。
Executor读holo表本地文件报文件不存在—Executor未正确挂载物理机上的tserver数据目录
现场任务失败， 看到报错 file not found exception
先确认数据是否存在
去到物理机上的相应目录上查看， 如果数据不存在， 说明确实丢了。 如果数据是存在的，则说明是其它问题。此次SLA中数据在物理机上是存在的。
这个时候怀疑可能是挂载问题， 应在物理机上使用 findmnt | grep "shiva-tabletserver-argodbstorage1" 去查看一下挂载
上面这张图的意思是： argodbstorage1 （即tablet server） 和 argodbcomputing1 （即executor）都正确的将目录挂载到物理机对应的路径上 ， 这是正常情况。
如果是挂载问题， 往往是argodbstorage 或者 argodbcomputing 至少有一个没挂好， 即要么没挂载， 要么没挂在到正确的路径上。
这个SLA是executor没有挂载好。
去检查executor pod 中的数据目录， 发现是空的（注意pod中的路径比物理机中的路径多一个 /vdir 即pod中路径开头为 /vdir/mnt/）
为解决这个挂载问题， 配置服务， 重启了该节点的executor pod（配置服务会重新触发挂载）
重启完之后再次查看executor 的数据目录， 已经正常了。
集群状态异常
shiva webui报错 server warning中包含io fails
检查tabletserver的ERROR日志
-
磁盘空间不足：去tabletserver的ERROR中搜索 no space left
-
磁盘损坏 ：磁盘无法访问
副本损坏
少数派副本 损坏： 对于3副本的表，数量为1个；对于5副本的表，数量为1个或2个
shiva 1.9 及之前，需要手动介入
curl -X DELETE "<host>:<port>/replica?namespace=<namespace>&tablename=<tablename>&tabletname=<tabletname>&server=<serveraddress>"
shiva 1.10开始， 会定时进行检测并且自动处理损坏的副本。 如需立即触发，可以使用restful触发 data balance ：
curl -XPOST "ip:port/cluster/balance?action=data?pretty"
多数派损坏 ：对于3副本的表，数量到达2个或以上；对于5副本的表，数量到达3个或以上
使用repair cluster进行处理(须在专业人员指导下操作)
手工修改 tablet group(须在专业人员指导下操作)
Webserver异常
/usr/lib/shiva-webserver/plugin/install.sh报错：active tabletserver数量不足
init master group failed
