空集群clog写入磁盘量太大

OceanBase 技术问题
#1

【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
【 使用版本 】
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)
生产环境社区版本4.2.3.0
新装集群3*3个节点，其中clog单独使用一张磁盘，型号为Samsung SSD 870 EVO 2TB。空转状态下发现磁盘写入量较大。1个小时的数据量如下。该情况是否正常？
节点编号,ob日志盘(MB),ob数据盘(MB),其他olap数据盘(MB)
154,3344,242,810
155,4164,573,24
156,2969,281,811
157,3357,177,23
158,4176,273,31
159,2967,171,23
161,3343,216,19
163,4162,344,34
166,2975,171,23

#4

按照这个文档中提及的第二步和第四步，提供一下巡检和日志分析的结果看看：【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

#5

SELECT * FROM DBA_OB_UNIT_CONFIGS;

你查看一下有多少个unit

#6

UNIT_CONFIG_ID | NAME | CREATE_TIME | MODIFY_TIME | MAX_CPU | MIN_CPU | MEMORY_SIZE | LOG_DISK_SIZE | MAX_IOPS | MIN_IOPS | IOPS_WEIGHT |
±---------------±----------------±---------------------------±---------------------------±--------±--------±------------±--------------±--------------------±--------------------±------------+
| 1 | sys_unit_config | 2024-06-18 15:42:38.951428 | 2024-06-18 15:42:38.951428 | 4 | 4 | 2147483648 | 6442450944 | 9223372036854775807 | 9223372036854775807 | 4 |
| 1001 | ocp_unit | 2024-06-18 15:44:25.911380 | 2024-06-18 15:44:25.911380 | 2 | 2 | 3221225472 | 8053063680 | 9223372036854775807 | 9223372036854775807 | 2

#7

先给个obdiag check的巡检结果看看能扫出来点问题吗。

另外，你说的空转集群，这个集群中还没导入过数据吗

#8

Error:4.2,3.0 not support gatherclog/slog

#9

不是采集clog和slog。是执行“obdiag check” 做巡检。

#10

没有导入数据，只装了ocp

#11

check_report_observer_2024-06-20-15-32-56.txt (52.2 KB)

#12

从巡检报告上看还好没有critical级别的提示，再拿点集群基础数据回来我看一下。

obdiag gather scene run --scene=observer.base

#13

没有你说的observer.base这个选项啊啊
bdiag gather scene run --scene=observer.backup [backup problem] [数据备份问题]
obdiag gather scene run --scene=observer.backup_clean [backup clean] [备份清理问题]
obdiag gather scene run --scene=observer.clog_disk_full [clog disk full] [clog盘满]
obdiag gather scene run --scene=observer.cluster_down [cluster down] [集群无法连接]
obdiag gather scene run --scene=observer.compaction [compaction] [合并问题]
obdiag gather scene run --scene=observer.cpu_high [High CPU] [CPU高]
obdiag gather scene run --scene=observer.delay_of_primary_and_backup [delay of primary and backup] [主备库延迟]
obdiag gather scene run --scene=observer.io [io problem] [io问题]
obdiag gather scene run --scene=observer.log_archive [log archive] [日志归档问题]
obdiag gather scene run --scene=observer.long_transaction [long transaction] [长事务]
obdiag gather scene run --scene=observer.memory [memory problem] [内存问题]
obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}” [SQL performance problem] [SQL性能问题]
obdiag gather scene run --scene=observer.px_collect_log --env “{trace_id=‘Yxx’, estimated_time=‘2024-06-20 18:06:55’}” [Collect error source node logs for SQL PX] [SQL PX 收集报错源节点日志]
obdiag gather scene run --scene=observer.recovery [recovery] [数据恢复问题]
obdiag gather scene run --scene=observer.restart [restart] [observer无故重启]
obdiag gather scene run --scene=observer.rootservice_switch [rootservice switch] [有主改选或者无主选举的切主]
obdiag gather scene run --scene=observer.sql_err --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}” [SQL execution error] [SQL 执行出错]
obdiag gather scene run --scene=observer.suspend_transaction [suspend transaction] [悬挂事务]
obdiag gather scene run --scene=observer.unit_data_imbalance [unit data imbalance] [unit迁移/缩小 副本不均衡问题]
obdiag gather scene run --scene=observer.unknown [unknown problem] [未能明确问题的场景]

#14

obdiag 2.2.0 版本才有，更新一下吧。

另外我注意到你的集群是有ocp_unit的，是不是除了业务租户之外，ocp meta租户和monitor租户也在一起。如果是的话，ocp monitor租户是用于ocp_agent采集的各种监控数据的存储的，这个clog占用也算合理

#15

@林明泉

如果你这个数据库作为ocp 的metadb, 那它有不少的读写量.

另外有一点, 如果作为ocp的metadb, 那你ocp_unit 资源太少了, 压力会比较大

#16

我装的2.9.2