签到成功

知道了

CNDBA社区CNDBA社区

OceanBase disk is almost full 解决方法

2023-12-07 15:32 271 0 原创 OceanBase
作者: dave

1 现象说明

报表的OceanBase数据库集群的发出如下告警:

告警概述:alarm_template_id=0:ob_cluster=myoceanbase-1:host=192.168.1.21:server_type=observer:error_code=4184:keyword= OBServer 程序日志

告警详情:[OBServer 程序日志] 集群:myoceanbase,主机:192.168.1.21,日志类型:observer,日志文件:/home/admin/myoceanbase/oceanbase/log/observer.log,日志级别:error,关键字=,错误码=4184,TraceId=YB420A69D015-000606463BB26CE3-0-0,日志详情=[2023-12-06 11:32:03.337235] ERROR check_space_full (ob_local_device.cpp:1316) [7993][T1020_L0_G0][T1020][YB420A69D015-000606463BB26CE3-0-0] [lt=25][errcode=-4184] Server out of disk space(msg=”disk is almost full”, ret=-4184, required_size=2097152, required_count=1, free_count=84479, used_percent=90) 。

这里提示的说的很清楚:T1020租户的 datafile 使用率超过 90%。 同时告警在触发 10 分后自动恢复,使用率下大幅下降。

2 原因过程

告警日志中有一个 traceid:YB420A69D015-000606463BB26CE3-0-0,但通过V$OB_SQL_AUDIT视图并查不到 SQL 的信息,返回为空。

obclient [oceanbase]> select trace_id,sid,sql_id,query_sql from V$OB_SQL_AUDIT;

首先看我们错误现象的本身:”disk is almost full”, 这里提示也直接,datafile_size 使用率过高,这个本身是一个很正常的现象,就和 Oracle 的表空间一样,随着数据的增加,数据文件使用率也会不断上升,正常情况下,我们直接调整这个参数即可,这是一个动态的参数:http://www.cndba.cn/dave/article/131476

obclient [oceanbase]> SHOW PARAMETERS LIKE '%datafile_size%'/G
*************************** 1. row ***************************
      zone: zone1
  svr_type: observer
    svr_ip: 192.168.1.21
  svr_port: 2882
      name: datafile_size
 data_type: NULL
     value: 1500G
      info: size of the data file. Range: [0, +∞)
   section: SSTABLE
     scope: CLUSTER
    source: DEFAULT
edit_level: DYNAMIC_EFFECTIVE

obclient [oceanbase]> select svr_ip,svr_port,
    -> round(total_size/1024/1024/1024,2) total_size, 
    -> round(used_size/1024/1024/1024,2) used_size,
    -> round(free_size/1024/1024/1024,2) free_size
    -> from __all_virtual_disk_stat;
+---------------+----------+------------+-----------+-----------+
| svr_ip        | svr_port | total_size | used_size | free_size |
+---------------+----------+------------+-----------+-----------+
| 192.168.1.21 |     2882 |    1500.00 |    264.31 |   1235.68 |
| 192.168.1.22 |     2882 |    1500.00 |    265.12 |   1234.88 |
| 192.168.1.23 |     2882 |    1500.00 |    264.77 |   1235.23 |
+---------------+----------+------------+-----------+-----------+
3 rows in set (0.003 sec)

但实际上我们查询 datafile 总的是 1.5T,单个数据文件的使用率并不高。 所以我们这里不是这个原因。

官方有一个类似的案例,如下:http://www.cndba.cn/dave/article/131476

https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000209971?back=kb

OceanBase HashGroup By 时发生了磁盘写入的操作,可以推断是在 SQL 执行的过程中产生了临时数据的落盘操作,有大 SQL 执行。 我们通过 OCP 平台也抓到了对应时间段内的 SQL,

http://www.cndba.cn/dave/article/131476

http://www.cndba.cn/dave/article/131476
http://www.cndba.cn/dave/article/131476

通过和业务沟通,发现是用户在报表查询的时候,选择了跨度很长的时间,从而导致 SQL 性能下降。 http://www.cndba.cn/dave/article/131476http://www.cndba.cn/dave/article/131476

通过分析基本可以定位是复杂的大查询产生了临时数据导致的告警。 这个只是一个诱因,实际上我们进一步分析,可以发现,总文件 1.5T,当前使用 260G 的情况下,临时查询使用了 90% 的空间,差不多 1T,这个明显也是不正常的。 最终在原厂的支持下,确认是版本的 bug。我们当前使用的版本是 4.1.1。 在 OB 4.2.0 后的版本中修复了该问题。

修复在磁盘负载过高的场景下,临时文件 I/O 异常可能导致的集群报错 4184 磁盘满的问题。
http://www.cndba.cn/dave/article/131476

3 解决方法

基于之前的问题,可以从诱因和 DB 两个层面解决:

  1. 优化 SQL 语句,缩短查询时间,避免大量的排序使用较多的临时数据。
  2. 升级OB 版本到 4.2.0+。

这里有个注意事项,就是大事务会占用磁盘空间,如果磁盘申请空间失败,只会导致这个大事务失败,然后回滚,释放相关的磁盘空间,并不会对整个集群有影响。http://www.cndba.cn/dave/article/131476http://www.cndba.cn/dave/article/131476

版权声明:本文为博主原创文章,未经博主允许不得转载。

用户评论
* 以下用户言论只代表其个人观点,不代表CNDBA社区的观点或立场
dave

dave

关注

人的一生应该是这样度过的:当他回首往事的时候,他不会因为虚度年华而悔恨,也不会因为碌碌无为而羞耻;这样,在临死的时候,他就能够说:“我的整个生命和全部精力,都已经献给世界上最壮丽的事业....."

  • 2237
    原创
  • 2
    翻译
  • 535
    转载
  • 185
    评论
  • 访问:6531556次
  • 积分:4229
  • 等级:核心会员
  • 排名:第1名
精华文章
    最新问题
    查看更多+
    热门文章
      热门用户
      推荐用户
        Copyright © 2016 All Rights Reserved. Powered by CNDBA · 皖ICP备2022006297号-1·

        QQ交流群

        注册联系QQ