主节点block_file比其他节点大

【 使用环境 】生产环境
【 OB or 其他组件 】ob
【 使用版本 】ob 4.3.5.1
【问题描述】三副本部署,有一个节点block_file都2.1T了,另外两个都是600G,不应该都是一样的吗,而且我的实际数据可能才10来个G,这2.1T虽然在最大配置允许内,但还是太大了,block_file增长逻辑是什么,怎么可以降下来
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接(右键跳转查看):

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)
image
image

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试,在发帖时输入 [@论坛小助手] 即可召唤小助手,欢迎试用!

1 个赞

根据您的描述,您遇到的问题是在三副本部署的OceanBase 4.3.5.1版本生产环境中,一个节点上的block_file大小异常增长到了2.1T,而其他两个节点保持在600G左右。这种情况下,首先我们需要通过日志收集来了解更详细的背景信息,然后才能确定具体的原因和解决方案。

日志采集场景: unit迁移/缩小 副本不均衡问题
日志采集命令:

obdiag gather scene run --scene=observer.unit_data_imbalance

这个命令可以帮助我们收集与单元间数据不平衡相关的信息,包括但不限于日志文件、配置文件以及运行时状态等,有助于分析导致单个节点block_file异常增大的原因。

另外,为更好地帮助您解决问题,请提供以下额外的信息:

  1. 这个block_file大小异常增长的现象是从什么时候开始出现的?最近是否执行过如大规模导入数据、更新统计信息或进行过表结构变更等操作?
  2. 目前该集群的日志归档策略是什么样的?是否有设置合理的清理策略?
  3. 您能否提供受影响节点与其他正常节点上主要性能指标(如磁盘使用率、IOPS)的对比情况?这将有助于我们理解是否存在资源竞争或者其他潜在瓶颈。
  4. 在发现此问题之前,集群内是否有发生过任何维护活动(例如升级、扩容或者重新平衡负载)?如果有的话,请详细说明这些活动的时间线及内容。
  5. 能否分享一下关于整个集群配置的基本概述,特别是涉及到存储相关的设置,比如单位规格、副本数量等信息?

以上信息对我们深入理解问题背景非常重要,希望您能配合提供。同时,也请执行上述的日志采集命令并将生成的日志包发给我们以便进一步诊断。

附上敏捷诊断工具 obdiag 使用帮助链接

select zone,concat(SVR_IP,’:’,SVR_PORT) observer,
cpu_capacity_max cpu_total,cpu_assigned_max cpu_assigned,
cpu_capacity-cpu_assigned_max as cpu_free,
round(memory_limit/1024/1024/1024,2) as memory_total,
round((memory_limit-mem_capacity)/1024/1024/1024,2) as system_memory,
round(mem_assigned/1024/1024/1024,2) as mem_assigned,
round((mem_capacity-mem_assigned)/1024/1024/1024,2) as memory_free,
round(log_disk_capacity/1024/1024/1024,2) as log_disk_capacity,
round(log_disk_assigned/1024/1024/1024,2) as log_disk_assigned,
round((log_disk_capacity-log_disk_assigned)/1024/1024/1024,2) as log_disk_free,
round((data_disk_capacity/1024/1024/1024),2) as data_disk,
round((data_disk_in_use/1024/1024/1024),2) as data_disk_used,
round((DATA_DISK_ALLOCATED/1024/1024/1024),2) as DATA_DISK_ALLOCATED,
round((data_disk_capacity-data_disk_in_use)/1024/1024/1024,2) as data_disk_free
from oceanbase.gv$ob_servers;

SELECT d.TENANT_ID, e.TENANT_NAME, concat(d.NAME, ': ', c.NAME) pool:conf,concat(d.UNIT_COUNT, ’ unit: ', c.min_cpu, ‘C/’, ROUND(c.MEMORY_SIZE/1024/1024/1024,0), “G”) unit_info
from __all_unit_config c
inner join __all_resource_pool d on c.UNIT_CONFIG_ID=d.UNIT_CONFIG_ID and (d.TENANT_ID = -1 or d.TENANT_ID>1000)
left join __all_tenant e on d.TENANT_ID=e.TENANT_ID;

信息 查一下看看



52节点的datafile确实分配了2100GB,其它2个副本分配了600GB,3个副本实际数据盘用量都是4GB左右,52节点的datafile可能是单独设置调大过,后面又调回600GB,但是datafile 不支持调小


后面这个参数 你们重新设置过么?


没改过,就我一个人维护,最近一次改动就是昨天改了unit


这我都是白屏按集群粒度改的,也没改过,租户都没这个参数

信息查一下看看
SELECT TENANT_ID,TENANT_NAME,TENANT_TYPE,PRIMARY_ZONE,LOCALITY FROM oceanbase.DBA_OB_TENANTS;

SELECT TENANT_ID, LS_ID, STATUS, PRIMARY_ZONE, UNIT_GROUP_ID, LS_GROUP_ID FROM oceanbase.CDB_OB_LS;

SELECT UNIT_ID, TENANT_ID, UNIT_GROUP_ID, ZONE, SVR_IP, SVR_PORT FROM oceanbase.DBA_OB_UNITS;

select * from oceanbase.__all_rootservice_event_history where module=‘ddl scheduler’; sys租户查看





按这个配置 不会有一个节点的datafile_size突然从600G增大到2100G 而其它副本节点不变化的,
不能确定是什么时间增大是吧?尝试搜日志看下

grep -i "alter_system\|set_config\|datafile_size" /实际路径/log/observer.log*

不过确实不支持datafile_size直接调小,可以通过删除节点 再增加节点的方式 来调小

你查一下这个信息
SELECT tenant_id, file_type,
SUM(used_size) / POWER(1024,3) AS used_gib,
SUM(data_size) / POWER(1024,3) AS data_gib
FROM oceanbase.__all_space_usage
WHERE svr_ip = ‘172.14.202.52’
AND svr_port = 2882
GROUP BY tenant_id, file_type
ORDER BY SUM(used_size) DESC;

之前有反馈使用的不一样 你这个不是使用 这个不好确定 如果需要缩小建议按照旭辉老师操作一下 你这个搭建的时候 是一起搭建的么?不是后来扩容的是么?

那只能重装节点了,一起搭的三副本,期间53挂了重装到了153

主要日志也应该查不出来了 不确定什么因素影响的

前两天还断电了,直接点重装就可以吧,日志备份要不要停


你是怎么做的备份呀 ocp上看着怎么是在52节点上

52做nfs 挂到153、54上