【 使用环境 】生产环境 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
SELECT * FROM DBA_OB_UNIT_CONFIGS;
你查看一下有多少个unit
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
先给个obdiag check的巡检结果看看能扫出来点问题吗。
另外，你说的空转集群，这个集群中还没导入过数据吗
Error:4.2,3.0 not support gatherclog/slog
不是采集clog和slog。是执行“obdiag check” 做巡检。
没有导入数据，只装了ocp
从巡检报告上看还好没有critical级别的提示，再拿点集群基础数据回来我看一下。
obdiag gather scene run --scene=observer.base
没有你说的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] [未能明确问题的场景]
obdiag 2.2.0 版本才有，更新一下吧。
另外我注意到你的集群是有ocp_unit的，是不是除了业务租户之外，ocp meta租户和monitor租户也在一起。如果是的话，ocp monitor租户是用于ocp_agent采集的各种监控数据的存储的，这个clog占用也算合理
我装的2.9.2
