OceanBase disk is almost full 解决方法 -- cnDBA.cn

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) 。http://www.cndba.cn/dave/article/131476

这里提示的说的很清楚：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 的表空间一样，随着数据的增加，数据文件使用率也会不断上升，正常情况下，我们直接调整这个参数即可，这是一个动态的参数：

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 http://www.cndba.cn/dave/article/131476

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

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

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

修复在磁盘负载过高的场景下，临时文件 I/O 异常可能导致的集群报错 4184 磁盘满的问题。

3 解决方法

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

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

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

签到成功

CNDBA社区