GBase 8a
运维管理
文章

GBase 8a集群巡检方法

地平线
发表于2025-09-18 17:08:12133次浏览1个评论

根据项目经验，总结常用GBase 8a集群巡检方法如下：

检查类别

检查项目

项目说明

检查方法

硬件状态

CPU检查集群硬件状态是否正常1、根据硬件厂商的监测通知
2、使用root账户登录集群各节点，检查/var/log/messages是否有error信息
cexec data: 'cat /var/log/messages | grep -i erro | tail -n10'
内存
磁盘
网络
集群服务集群状态检查集群状态是否正常gbase账户登录集群管理节点，执行gcadmin，观察cluster_state是否为NORMAL
集群组件状态检查集群组件是否存在掉线、关闭的非正常情况gbase账户登录集群管理节点，执行gcadmin，观察gcware/gcluster/gnode/syncserver等各组件状态是否为OPEN
集群event检查集群是否长时间存在eventgbase账户登录集群管理节点，执行gcadmin，观察DataState列值是否为0
集群组件宕机情况检查集群组件近期是否有宕机的情况gbase账户登录集群管理节点，执行下列命令检查宕机情况：
cexec coor: 'ls -l /gbase/gcluster/userdata/core.*'
cexec coor: 'ls -l /gbase/gcluster/userdata/*.dump'
cexec data: 'ls -l /gbase/gnode/userdata/core.*'
cexec data: 'ls -l /gbase/gnode/userdata/*.dump'

集群业务

集群任务积压情况检查集群近期是否存在长时间任务数过高的情况检查近期的集群任务数趋势，检查是否存在长时间任务数过高（积压）的情况。统计周期一般可选一周，高任务数根据集群业务场景不同，参考值200。备注：任务数趋势统计及日志表的设计实现此处不冗述。
集群任务耗时情况检查集群近期是否存在超长SQL数量过大的情况通过集群审计日志表gclusterdb.audit_log_express，统计近期各分档耗时SQL任务数，查看超长SQL的数量是否过大。

统计周期一般可选最近一周，任务时长分档根据集群业务场景而定，一般而言，集市集群这类IO密集型集群可将分档设置为5分钟、10分钟、20分钟、30分钟、60分钟，重点观察30或60分钟以上的任务数。前台库手机经分这类小查询高并发集群可将分档设置为5秒、10秒、30秒、60秒、180秒，重点观察60秒、180秒以上的任务数。

超长SQL数量是否过大，可采用相对比例法或与历史比对法判断。比如：前台库集群，99.5%的查询都在3秒以内，超过180秒的占比不足千分之一，可认为集群是比较正常的。

统计SQL如下：
-- SQL耗时统计（秒级任务为主的集群）
select
to_char(start_time, 'yyyymmdd') start_day
, count(1) all_sql 
, sum(case when query_time < '00:00:03' then 1 else 0 end) 3s_sql
, sum(case when query_time >= '00:00:03' and query_time < '00:00:05' then 1 else 0 end) 5s_sql
, sum(case when query_time >= '00:00:05' and query_time < '00:00:10' then 1 else 0 end) 10s_sql
, sum(case when query_time >= '00:00:10' and query_time < '00:00:30' then 1 else 0 end) 30s_sql
, sum(case when query_time >= '00:00:30' and query_time < '00:00:60' then 1 else 0 end) 60s_sql
, sum(case when query_time >= '00:00:60' and query_time < '00:03:00' then 1 else 0 end) 180s_sql
, sum(case when query_time > '00:03:00' then 1 else 0 end) 180sp_sql
, sum(case when query_time < '00:00:03' then 1 else 0 end) / count(1)
from gclusterdb.audit_log_express
where start_time between sysdate() - 7 and sysdate()
and sql_command not in ('LOAD') and upper(sql_text) not like ('%into outfile%')
group by
to_char(start_time, 'yyyymmdd')
order by to_char(start_time, 'yyyymmdd');

-- SQL耗时统计（分钟级任务为主的集群）
select
to_char(start_time, 'yyyymmdd') start_day
, sum(1) cnt_all
, sum(case when query_time < '00:05:00' then 1 else 0 end) cnt_5
, sum(case when query_time >= '00:05:00' and query_time < '00:10:00' then 1 else 0 end) cnt_5_10
, sum(case when query_time >= '00:10:00' and query_time < '00:20:00' then 1 else 0 end) cnt_10_20
, sum(case when query_time >= '00:20:00' and query_time < '00:30:00' then 1 else 0 end) cnt_20_30
, sum(case when query_time >= '00:30:00' and query_time < '00:60:00' then 1 else 0 end) cnt_30_60
, sum(case when query_time >= '00:60:00' then 1 else 0 end) cnt_1h
,  sum(case when query_time < '00:05:00' then 1 else 0 end) / sum(1) cnt_5_percent
from gclusterdb.audit_log_express
where start_time between sysdate() - 7 and sysdate()
and sql_command not in ('LOAD') and upper(sql_text) not like ('%into outfile%')
group by
to_char(start_time, 'yyyymmdd')
order by to_char(start_time, 'yyyymmdd');
异常任务情况检查近期超大SQL、超时SQL的情况，检查是否有过多的此类任务通过相关监控日志表统计超大、超时SQL的总体情况，通过相关异常SQL日志表查看超大、超时SQL详情。一般来说，异常任务只是偶尔或零星少量出现，是比较理想的。备注：日志表的设计实现此处不冗述。
系统资源CPU使用率检查近期CPU使用率，是否存在使用率过高的情况，参考值80%抽取近期集群第1个节点的nmon日志分析，重点观察CPU使用率趋势、磁盘Busy趋势、Swap使用率趋势，看是否存在瓶颈。统计周期参考：每周三，使用率阈值参考：80%。
内存使用率检查近期内存使用率，是否存在使用率过高的情况，重点检查Swap使用率，参考值80%
磁盘Busy检查近期磁盘Busy使用率，是否存在使用率过高的情况，参考值80%
系统盘使用率检查系统盘空间使用率，是否存在使用率过高的情况，参考值80%用gbase账户登录管理节点，使用下列指令查看各节点系统盘空间使用率，检查是否超过阈值（80%）。
cexec data: 'df -h|grep -w "/"'
数据盘使用率检查数据盘空间使用率，是否存在使用率过高的情况，参考值80%用gbase账户登录管理节点，使用下列指令查看各节点数据盘空间使用率，检查是否超过阈值（80%）。
cexec data: 'df -h|grep gbase'
数据盘iNode使用率检查数据盘iNode使用率，是否存在使用率过高的情况，参考值80%用gbase账户登录管理节点，使用下列指令查看各节点数据盘空间使用率，检查是否超过阈值（80%）。
cexec data: 'df -i|grep gbase'

集群数据

数据倾斜情况检查各节点数据盘空间使用率，是否存在差异过大的情况。一般来说，数据倾斜在5%以内是比较正常的。检查集群各节点数据是否存在倾斜情况，一般来说，数据倾斜在5%以内是比较正常的。
用gbase账户登录管理节点，使用下列指令查看：
cexec data: 'df -h|grep gbase'
元数据规模检查集群表、视图个数，是否存在数量过大的情况。
元数据过大对集群性能及节点替换等运维操作有不利影响。参考数据：某集群表25万、视图85万，元数据大小37G，管理节点扩容打包元数据耗时4小时。
建议定期清理表、视图，将元数据控制在相对较小的规模。表、视图数量控制在10万级别以下，是更好的。		统计表、视图的个数，检查是否存在表、视图数量过大的情况，统计语句如下：
统计表、视图数：
select table_type,count(1) from information_schema.tables group by table_type;
统计表数：
select count(1) from gbase.table_distribution;
授权数据情况检查授权记录数是否存在过大的情况。授权记录数过大会引起的show databases等语句执行变慢的问题，可通过清理异常授权记录（表已删除）缓解。授权记录数过大参考阈值：100万。通过gbase账户登录集群管理节点，通过下列命令检查：
检查集群层授权记录数：
gccli -ugbase -p -e"select count(1) from gbase.tables_priv;
检查节点层授权记录数：
gncli –ugbase -p -e"select count(1) from gbase.tables_priv;
tableid(V8-Build43以下)V862Build43以下版本，正式表tableid取值范围为1~2147483647（约21.4亿），临时表tableid取值范围1073741823（约10.7亿）~ 2147483647（约21.4亿），如果正式表数量过大，tableid超过10.7亿，可能会出现中间临时表tableid与gnode层表tableid的冲突，导致gbased宕机，冲突的条件需要正式表、临时表同时打开。V862Build43及以上版本，正式表tableid取值范围为1~9223372034707292160，9223372034707292161~9223372036854775806，几乎可认为是无限量，存在冲突的可能性极低。通过gcware接口gettableid()获取tableid，检查是否接近10.7亿。如tableid接近10.7亿，可采用手工调整临时表ID的方法绕行

评论

登录后才可以发表评论
用户头像
GBase用户28017发表于 9个月前
学习了。

热门帖子