工作负载运行过程中 LSMTree 不同类型 SSTable 数量及大小的查询

【 使用环境 】测试环境
【 OB or 其他组件 】Oceanbase 社区版 三节点分布式集群
【 使用版本 】V 4.3.5
【问题描述】

在工作负载运行过程中 LSMTree 不同类型 SSTable 数量及大小的查询

背景

资源池 和 租户建立

CREATE RESOURCE POOL tpcc_pool_01 
UNIT='tpcc_unit_config', UNIT_NUM=1, ZONE_LIST=('zone1','zone2','zone3'); 

CREATE TENANT IF NOT EXISTS tpcc_tenant1 
RESOURCE_POOL_LIST=('tpcc_pool_01'), 
PRIMARY_ZONE='zone1', zone_list('zone1', 'zone2', 'zone3'), 
locality='F@zone1,F@zone2,F@zone3' 
set variables ob_compatibility_mode='mysql', 
ob_tcp_invited_nodes='%';

查询 SSTable 语句

SELECT l.database_name, l.table_name, m.svr_ip, m.table_type 
    , m.size as size_bytes  -- 直接列出每个 table_type 的大小(字节)
	, round(m.size/1024/1024,2) data_size_mb 
FROM GV$OB_SSTABLES m 
join oceanbase.cdb_ob_table_locations l 
on (m.tenant_id=l.tenant_id and m.tablet_id=l.tablet_id)
WHERE m.tenant_id=1002 
	and l.database_name in ('ob_sysbench')  
	and l.table_name in ('sbtest1')
ORDER BY l.database_name, l.table_name, m.svr_ip, m.table_type;

问题

在 sysbench insert 过程中,使用上述 SQL 语句查询。

在184节点上面查询出来 相同类型 相同大小 的SSTable有三个。

是因为本地三副本,还是因为184节点可以获取其他节点副本的信息。如果显示的是其他节点的信息,为什么184和118节点查询出来的SSTable 大小不同,是因为统计的延迟吗?

【复现路径】
【附件及日志】

@论坛小助手

1 个赞

日志采集场景: 合并问题
日志采集命令: obdiag gather scene run --scene=observer.compaction

推荐使用 obdiag 工具进行日志采集,以便我们更好地了解集群的合并状态和 SSTable 的分布情况。通过采集到的日志,我们可以进一步分析为什么不同节点查询出来的 SSTable 数量和大小存在差异。

为了更准确地诊断问题,请您提供以下信息:

  1. 在 184 和 118 节点上执行的具体 SQL 查询语句是什么?是否可以提供完整的查询语句以便我们复现问题?
  2. 您提到的“特定 SQL 查询 LSMTree 不同类型 SSTable 的数量及大小”,是否可以确认该 SQL 是否针对本地数据还是全局数据进行查询?
  3. 集群中是否有正在进行的合并(compaction)操作?如果有,请提供相关的时间范围以便我们在日志中定位相关信息。
  4. 184 和 118 节点的角色分别是什么(Leader 还是 Follower)?这些角色是否在测试过程中发生了切换?
  5. 集群当前的副本分布情况如何?是否可以通过 SHOW PARTITIONS 或其他相关命令查看具体的分区和副本分布?
  6. 是否可以确认 184 和 118 节点之间的网络延迟或同步延迟是否存在异常?

请您根据上述命令采集日志,并将日志压缩包提供给我们以供进一步分析。

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

1 个赞

合理的,只有major 限制了副本要一样,mini/minor没有限制, compaction的触发是随机的

还想请问“在184节点上面查询出来 相同类型 相同大小 的SSTable有三个(比如图中显示的三个 MINI_SSTable)” 这个状态,是184节点自身具有3个MINI_SSTable,还是说184节点只有1个MINI_SSTable,另外两个相同SSTable的是184节点认为的副本应该的大小。

根据文档库中的信息,可以对您的问题进行如下解答:

1. 关于 SSTable 的查询结果

在 OceanBase 数据库中,GV$OB_SSTABLES 视图展示了每台 OBServer 节点上的各分区下的 MemTable 和 SSTable 信息(参考片段标题:GV$OB_SSTABLES -> 功能)。这意味着查询结果是基于当前节点的视角,展示的是该节点上存储的 SSTable 信息。

因此,当您在 184 节点上查询到相同类型、相同大小的 SSTable 有三个时,这可能是因为以下两种情况之一:

  • 本地存储了多个副本:如果 184 节点本身存储了多个副本(例如 Leader 副本和 Follower 副本),那么它会显示这些副本对应的 SSTable。
  • 全局视图展示:虽然 GV$OB_SSTABLES 是全局视图,但它实际上只展示当前节点上实际存储的数据。因此,184 节点不会显示其他节点上的 SSTable 信息,除非这些 SSTable 是通过分布式查询逻辑拉取的。

2. 三副本机制的影响

OceanBase 使用三副本机制,默认情况下每个分区会有三个副本(一个 Leader 副本和两个 Follower 副本)。每个副本都会独立生成自己的 SSTable,并且这些 SSTable 的内容理论上应该是一致的(参考片段标题:转储和合并 -> 合并时数据不一致)。

因此,如果您在 184 节点上看到三个相同类型的 SSTable(如 MINI_SSTable),这通常意味着:

  • 184 节点自身存储了这三个 SSTable,可能是由于该节点同时承担了多个副本的角色(Leader 和 Follower)。
  • 或者,这些 SSTable 是由不同的分区或 Tablet 生成的,但它们的大小和类型恰好相同。

3. 为什么不同节点查询出来的 SSTable 大小不同?

不同节点查询出来的 SSTable 大小不同,可能的原因包括:

  • 合并状态差异:不同节点上的副本可能处于不同的合并状态(例如,某些节点正在进行 Minor Merge 或 Major Merge),导致 SSTable 的数量和大小存在差异。
  • 延迟同步:Follower 副本可能会有一定的延迟,导致其 SSTable 的生成时间与 Leader 副本不一致。
  • 数据分布差异:即使副本之间数据一致,但由于分区内并行处理(如 tablet_size 参数设置)的不同,可能导致生成的 SSTable 大小略有差异。

4. 如何确认具体原因?

为了进一步确认 184 节点上显示的 SSTable 是否为本地存储的副本,您可以尝试以下步骤:

  • 检查副本分布:使用 SHOW PARTITIONS 命令查看具体的分区和副本分布情况,确认 184 节点是否存储了多个副本。
  • 对比节点角色:通过 SHOW TENANTSHOW TABLET 命令查看各个节点的角色(Leader 或 Follower),确认是否存在多角色副本。
  • 采集日志:使用 obdiag gather scene run --scene=observer.compaction 命令采集合并相关的日志,分析 SSTable 的生成过程和状态。

总结

根据文档信息,184 节点查询到的三个相同类型的 SSTable 更可能是该节点自身存储的副本,而不是认为的其他节点副本的大小。不同节点查询结果的差异可能与合并状态、延迟同步或数据分布有关。建议通过上述方法进一步排查具体原因。

检索到的文档如下:

  1. 对象命名规范综述
  2. 使用限制
  3. V$OB_SSTABLES
  4. tablet_size
  5. SQL FAQ
  6. OceanBase 数据库整体架构
  7. auto_split_tablet_size
  8. 转储和合并
  9. GV$OB_SSTABLES

(小助手的答复已结束,如未能解决您的问题,请继续提问并等待其他同学的回复,谢谢!)

1 个赞

是184节点自身具有3个MINI_SSTable

默认情况下 minor_compact_trigger = 2,根据文档是有两个 mini_SSTable 会触发合并形成 minor_SSTable。

对于184节点 sbtest1 这个表分区,当一个表分区中存在大于 2个 mini_SSTable 时,应该是要触发 minor_merge 合并。

这张图获取的瞬间,这里显示有 9 个mini_SSTable,每三个具有相同的大小。

触发合并之后,形成 3 个相同的 minor_SSTable(如下图)。

如果每三个相同大小的表被认为一个表,符合 “大于 2个 mini_SSTable 时合并” 的逻辑。是 SQL 连接逻辑导致 SST able 重复出现吗?

或者说 184节点自身就存在 3 个副本吗? (好像也不是,因为 tanent_id 都是 202851)

sstable 和 表副本的关系 @论坛小助手

你可以看一下三个相同大小的sstable 他们LS_ID不一致

它们的 LS_ID 好像是一致的

麻烦查询时候把SVR_PORT,sstable的版本(UPPER_TRANS_VERSION,END_LOG_SCN)也输出一下看看

对于三个相同的SSTable,(UPPER_TRANS_VERSION,END_LOG_SCN)好像也是一样的

麻烦指定租户id和tablet_id 查询下select * from __all_virtual_table_mgr;

先使用之前的 sql 查找指定表名的 SSTable 分布情况

SELECT l.database_name, l.table_name, m.svr_ip, m.tablet_id
	, case m.table_type 
		when 10 then 'MAJOR_SSTABLE' 
		when 11 then 'MINOR_SSTABLE' 
		when 12 then 'MINI_SSTABLE' 
		when 17 then 'COLUMN_ORIENTED_SSTABLE' 
		when 18 then 'NORMAL_COLUMN_GROUP_SSTABLE' 
		when 21 then 'DDL_MERGE_CO_SSTABLE' 
		when 27 then 'MDS_MINOR_SSTABLE' 
		when 26 then 'MDS_MINI_SSTABLE'
		else concat(m.table_type,':','UNKOWN') end as mgr_table_type 
    , m.size as size_bytes  -- 直接列出每个 table_type 的大小(字节)
	, round(m.size/1024/1024,2) data_size_mb 
FROM oceanbase.__all_virtual_table_mgr m 
join oceanbase.cdb_ob_table_locations l 
on (m.tenant_id=l.tenant_id and m.tablet_id=l.tablet_id)
WHERE m.tenant_id=1002 
	and m.table_type >= 1  
	and l.database_name in ('ob_sysbench')  
	and l.table_name in ('sbtest1')
ORDER BY l.database_name, l.table_name, m.svr_ip, m.table_type;

结果是:

然后使用语句查询 __all_virtual_table_mgr 中信息:

select * from __all_virtual_table_mgr where tenant_id = "1002" and tablet_id = "202939" and svr_ip = "xxx.184"\G;

查询结果如下:

*************************** 1. row ***************************
                 svr_ip: xxx.184
               svr_port: 2882
              tenant_id: 1002
                  ls_id: 1001
             table_type: 10
              tablet_id: 202939
          start_log_scn: 0
            end_log_scn: 1742787184755683000
    upper_trans_version: 0
                   size: 76106772
       data_block_count: 38
      index_block_count: 0
     linked_block_count: 0
                    ref: 0
              is_active: NO
contain_uncommitted_row: NO
          nested_offset: 0
            nested_size: 2097152
                 cg_idx: 0
          data_checksum: 1442808960
             table_flag: 0
*************************** 2. row ***************************
                 svr_ip: xxx.184
               svr_port: 2882
              tenant_id: 1002
                  ls_id: 1001
             table_type: 11
              tablet_id: 202939
          start_log_scn: 1742786850751219000
            end_log_scn: 1742789368961603001
    upper_trans_version: 1742789368961603001
                   size: 7186251
       data_block_count: 5
      index_block_count: 0
     linked_block_count: 0
                    ref: 0
              is_active: NO
contain_uncommitted_row: NO
          nested_offset: 0
            nested_size: 2097152
                 cg_idx: 0
          data_checksum: 0
             table_flag: 0
*************************** 3. row ***************************
                 svr_ip: xxx.184
               svr_port: 2882
              tenant_id: 1002
                  ls_id: 1001
             table_type: 27
              tablet_id: 202939
          start_log_scn: 1
            end_log_scn: 1742786826258529004
    upper_trans_version: 1742786639680404001
                   size: 493
       data_block_count: 1
      index_block_count: 0
     linked_block_count: 0
                    ref: 0
              is_active: NO
contain_uncommitted_row: NO
          nested_offset: 876544
            nested_size: 4096
                 cg_idx: 0
          data_checksum: 0
             table_flag: 0
*************************** 4. row ***************************
                 svr_ip: xxx.184
               svr_port: 2882
              tenant_id: 1002
                  ls_id: 1001
             table_type: 0
              tablet_id: 202939
          start_log_scn: 1742789368961603001
            end_log_scn: 4611686018427387903
    upper_trans_version: 9223372036854775807
                   size: 4194304
       data_block_count: 0
      index_block_count: 0
     linked_block_count: 0
                    ref: 2
              is_active: YES
contain_uncommitted_row: YES
          nested_offset: 0
            nested_size: 0
                 cg_idx: 0
          data_checksum: 0
             table_flag: 0
4 rows in set (0.05 sec)

你的集群架构是啥样

云上的三个节点

然后 资源池 和 租户建立 的语句是下面

CREATE RESOURCE POOL tpcc_pool_01 
UNIT='tpcc_unit_config', UNIT_NUM=1, ZONE_LIST=('zone1','zone2','zone3'); 

CREATE TENANT IF NOT EXISTS tpcc_tenant1 
RESOURCE_POOL_LIST=('tpcc_pool_01'), 
PRIMARY_ZONE='zone1', zone_list('zone1', 'zone2', 'zone3'), 
locality='F@zone1,F@zone2,F@zone3' 
set variables ob_compatibility_mode='mysql', 
ob_tcp_invited_nodes='%';

在另外一个帖子里,也发现了 SSTable 是3的倍数的问题。

图中查出来的 count(*) 都是 3 的倍数

这张图里三个sstable就是同一个sstable,cdb_ob_table_locations里有三副本信息,你的sql join以后就是会重复三条记录

2 个赞

所以是 sql join 的问题导致的。在 join 条件中增加 m.svr_ip = l.svr_ip 避免重复了。感谢!

SELECT l.database_name, l.table_name, m.svr_ip, m.tablet_id, m.table_type, 
	m.svr_port, m.END_LOG_SCN, m.UPPER_TRANS_VERSION, 
	m.size as size_bytes  -- 直接列出每个 table_type 的大小(字节)
	-- round(m.size/1024/1024,2) data_size_mb 
FROM GV$OB_SSTABLES m 
join oceanbase.cdb_ob_table_locations l 
on (m.tenant_id=l.tenant_id and m.tablet_id=l.tablet_id and m.svr_ip = l.svr_ip)
WHERE m.tenant_id=1002 
	and l.database_name in ('ob_sysbench')  
	and l.table_name like 'sbtest%'
ORDER BY l.database_name, l.table_name, m.svr_ip, m.table_type;

你好,该sql是在哪里找到的,这边看一下是否可以去修改掉

在这个问题下面