【 使用环境 】测试环境
【 OB or 其他组件 】
【 使用版本 】4.3.3
【问题描述】 测试从mysql全量数据迁移到oceanbase存储没有见明显变化,是什么原因
在原mysql存储是167G全量迁移到oceanbase是146G (sstable和clog 各占73G,)
使用oms迁移时那的ob表结构采用的压缩算法都是
DEFAULT CHARSET = utf8mb4 ROW_FORMAT = DYNAMIC COMPRESSION = ‘zstd_1.3.8’ REPLICA_NUM = 1 BLOCK_SIZE = 16384 USE_BLOOM_FILTER = FALSE TABLET_SIZE = 134217728 PCTFREE = 0;
2 个赞
OB 在初始化集群的时候,每个节点都预分配了内存和空间资源。你看到的空间是 OB 数据文件和事务日志文件占用的空间,这些是参数提前预占的。
OB 预占用的数据空间资源会在内部使用,OB 的转储和每日合并机制会让内部的实际使用空间呈现一个短期内呈现上下波动长期看有趋势上涨(前提是业务数据写一直在增加)。所以,你想看的是观察实际使用空间。用下面的SQL:
SELECT /*+ read_consistency(weak) query_timeout(1000000000) */ t1.tenant_id, t1.database_name, round(sum(t2.required_size)/1024/1024/1024) required_size_gb, count(*) cnt
FROM oceanbase.CDB_OB_TABLE_LOCATIONS t1
JOIN oceanbase.cdb_ob_tablet_replicas t2 ON (t1.tenant_id=t2.tenant_id and t1.tablet_id=t2.tablet_id AND t1.ls_id=t2.ls_id and t1.svr_ip=t2.svr_ip and t1.SVR_PORT=t2.svr_port )
WHERE t1.tenant_id in (1002) and t1.ROLE='LEADER'
GROUP BY t1.tenant_id, t1.database_name
;
SELECT /*+ read_consistency(weak) query_timeout(1000000000) */ t1.tenant_id, t1.database_name, round(sum(s.size)/1024/1024/1024) data_size_gb, count(*) cnt
FROM oceanbase.CDB_OB_TABLE_LOCATIONS t1
JOIN oceanbase.cdb_ob_tablet_replicas t2 ON (t1.tenant_id=t2.tenant_id and t1.tablet_id=t2.tablet_id AND t1.ls_id=t2.ls_id and t1.svr_ip=t2.svr_ip and t1.SVR_PORT=t2.svr_port )
JOIN oceanbase.GV$OB_SSTABLES s ON (t1.tenant_id=s.tenant_id AND t1.ls_id=s.ls_id AND t1.svr_ip=s.svr_ip and t1.SVR_PORT =s.svr_port AND t1.tablet_id=s.tablet_id)
WHERE t1.tenant_id in (1004) AND t1.ROLE='LEADER' AND s.table_type <> 'MEMTABLE'
GROUP BY t1.tenant_id, t1.database_name
;
有关 OB 空间初始化原理详细的可以看示例: OB 数据文件缩容技巧
1 个赞