论坛小助手
2025 年3 月 17 日 16:32
#3
日志采集场景: 合并问题
推荐使用 obdiag 工具进行日志采集，以便我们更好地了解集群的合并状态和 SSTable 的分布情况。通过采集到的日志，我们可以进一步分析为什么不同节点查询出来的 SSTable 数量和大小存在差异。
为了更准确地诊断问题，请您提供以下信息：
在 184 和 118 节点上执行的具体 SQL 查询语句是什么？是否可以提供完整的查询语句以便我们复现问题？
您提到的“特定 SQL 查询 LSMTree 不同类型 SSTable 的数量及大小”，是否可以确认该 SQL 是否针对本地数据还是全局数据进行查询？
集群中是否有正在进行的合并（compaction）操作？如果有，请提供相关的时间范围以便我们在日志中定位相关信息。
184 和 118 节点的角色分别是什么（Leader 还是 Follower）？这些角色是否在测试过程中发生了切换？
集群当前的副本分布情况如何？是否可以通过 SHOW PARTITIONS 或其他相关命令查看具体的分区和副本分布？
是否可以确认 184 和 118 节点之间的网络延迟或同步延迟是否存在异常？
请您根据上述命令采集日志，并将日志压缩包提供给我们以供进一步分析。
附上敏捷诊断工具 obdiag 使用帮助链接
1 个赞
辞霜
2025 年3 月 17 日 17:27
#4
合理的，只有major 限制了副本要一样，mini/minor没有限制， compaction的触发是随机的
若水
2025 年3 月 17 日 19:11
#5
还想请问“在184节点上面查询出来 相同类型 相同大小 的SSTable有三个（比如图中显示的三个 MINI_SSTable）” 这个状态，是184节点自身具有3个MINI_SSTable，还是说184节点只有1个MINI_SSTable，另外两个相同SSTable的是184节点认为的副本应该的大小。
论坛小助手
2025 年3 月 17 日 19:15
#6
根据文档库中的信息，可以对您的问题进行如下解答：
关于 SSTable 的查询结果
在 OceanBase 数据库中，GV$OB_SSTABLES 视图展示了每台 OBServer 节点上的各分区下的 MemTable 和 SSTable 信息（参考片段标题：GV$OB_SSTABLES -> 功能）。这意味着查询结果是基于当前节点的视角，展示的是该节点上存储的 SSTable 信息。
因此，当您在 184 节点上查询到相同类型、相同大小的 SSTable 有三个时，这可能是因为以下两种情况之一：
本地存储了多个副本 ：如果 184 节点本身存储了多个副本（例如 Leader 副本和 Follower 副本），那么它会显示这些副本对应的 SSTable。
全局视图展示 ：虽然 GV$OB_SSTABLES 是全局视图，但它实际上只展示当前节点上实际存储的数据。因此，184 节点不会显示其他节点上的 SSTable 信息，除非这些 SSTable 是通过分布式查询逻辑拉取的。
三副本机制的影响
OceanBase 使用三副本机制，默认情况下每个分区会有三个副本（一个 Leader 副本和两个 Follower 副本）。每个副本都会独立生成自己的 SSTable，并且这些 SSTable 的内容理论上应该是一致的（参考片段标题：转储和合并 -> 合并时数据不一致）。
因此，如果您在 184 节点上看到三个相同类型的 SSTable（如 MINI_SSTable），这通常意味着：
184 节点自身存储了这三个 SSTable ，可能是由于该节点同时承担了多个副本的角色（Leader 和 Follower）。
或者，这些 SSTable 是由不同的分区或 Tablet 生成的，但它们的大小和类型恰好相同。
为什么不同节点查询出来的 SSTable 大小不同？
不同节点查询出来的 SSTable 大小不同，可能的原因包括：
合并状态差异 ：不同节点上的副本可能处于不同的合并状态（例如，某些节点正在进行 Minor Merge 或 Major Merge），导致 SSTable 的数量和大小存在差异。
延迟同步 ：Follower 副本可能会有一定的延迟，导致其 SSTable 的生成时间与 Leader 副本不一致。
数据分布差异 ：即使副本之间数据一致，但由于分区内并行处理（如 tablet_size 参数设置）的不同，可能导致生成的 SSTable 大小略有差异。
如何确认具体原因？
为了进一步确认 184 节点上显示的 SSTable 是否为本地存储的副本，您可以尝试以下步骤：
检查副本分布 ：使用 SHOW PARTITIONS 命令查看具体的分区和副本分布情况，确认 184 节点是否存储了多个副本。
对比节点角色 ：通过 SHOW TENANT 或 SHOW TABLET 命令查看各个节点的角色（Leader 或 Follower），确认是否存在多角色副本。
采集日志 ：使用 obdiag gather scene run --scene=observer.compaction 命令采集合并相关的日志，分析 SSTable 的生成过程和状态。
根据文档信息，184 节点查询到的三个相同类型的 SSTable 更可能是该节点自身存储的副本，而不是认为的其他节点副本的大小。不同节点查询结果的差异可能与合并状态、延迟同步或数据分布有关。建议通过上述方法进一步排查具体原因。
检索到的文档如下:
对象命名规范综述 使用限制 V$OB_SSTABLES tablet_size SQL FAQ OceanBase 数据库整体架构 auto_split_tablet_size 转储和合并 GV$OB_SSTABLES
(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)
1 个赞
若水
2025 年3 月 18 日 15:27
#8
默认情况下 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)
辞霜
2025 年3 月 18 日 18:17
#11
你可以看一下三个相同大小的sstable 他们LS_ID不一致
辞霜
2025 年3 月 19 日 15:26
#14
麻烦查询时候把SVR_PORT,sstable的版本（UPPER_TRANS_VERSION，END_LOG_SCN）也输出一下看看
若水
2025 年3 月 19 日 18:42
#16
对于三个相同的SSTable，（UPPER_TRANS_VERSION，END_LOG_SCN）好像也是一样的
辞霜
2025 年3 月 20 日 10:21
#17
麻烦指定租户id和tablet_id 查询下select * from __all_virtual_table_mgr;
若水
2025 年3 月 24 日 14:53
#18
先使用之前的 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)
若水
2025 年3 月 24 日 16:36
#20
云上的三个节点
然后 资源池 和 租户建立 的语句是下面
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的倍数的问题。
像L0层内部分为level-0 到 level-n 层，怎么查询L0内部有多少层，和每层有多少 个sstable。
谢谢！
图中查出来的 count(*) 都是 3 的倍数
镜水
2025 年3 月 24 日 17:01
#21
这张图里三个sstable就是同一个sstable，cdb_ob_table_locations里有三副本信息，你的sql join以后就是会重复三条记录
2 个赞
若水
2025 年3 月 24 日 17:21
#22
所以是 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;
辞霜
2025 年3 月 24 日 18:04
#23
你好，该sql是在哪里找到的，这边看一下是否可以去修改掉
