--- title: 共享存储模式下合并丢数据-OceanBase数据库使用指南 description: 了解OceanBase数据库在实际应用中关于共享存储模式下合并丢数据相关的常见问题和使用技巧，帮助您快速解决共享存储模式下合并丢数据的难题。 --- 切换语言 - 简体中文 - English 划线反馈 # 共享存储模式下合并丢数据 更新时间：2026-06-12 08:51 适用版本： V4.3.x 内容类型：Troubleshoot ## 问题现象 共享存储模式，合并后出现查询结果丢失等正确性问题。 ## 关键诊断信息 ### 触发条件 1. LS Leader 所在的 OBServer。 2. 同一个 Tablet，假设 LS ID = 1001，TabletID = 200001。 3. 满足以下 TimeLine，其中，t1 和 t2 不区分先后。 | **时刻** | **线程 1 合并调度线程** | **线程 2 转储 Dag 线程** | **线程 3 SKIP MERGE DAG 线程** | | --- | --- | --- | --- | | t1 | | 200001 发起转储 | | | t2 | 1001 LS Leader 轮询到 200001 | | | | t3 | 拿到 200001 的 Tablet Handle | | | | t4 | | 200001 转储完成，从 MemTable mgr 上删除**所有**的已冻结 MemTable，同时 mgr 上不存在 Active MemTable | | | t5 | 未检查到 200001 上存在 MemTable，误判断为 Skip Merge | | | | t6 | 写下 NO INC DATA 的 CLOG | | | | t7 | | | 通过深拷旧 MAJOR 生成新 MAJOR，新 MAJOR 丢失了新写入的增量数据 | ### 事前巡检 无，尽快升级到带 Hotfix 的版本。 ### 事后诊断 1. 丢数据的分区在最近一轮合并中，走了 SKIP MERGE。 2. 该分区对应的 Leader 在写最近一轮合并的 Medium Clog 前，有**即将完成**的并发转储任务，并且该转储任务在收尾阶段清空了 MemTable mgr 上**所有的 Frozen MemTable**，同时该 Tablet 上不存在 Active MemTable。 **以下为关键日志：** 1. LS Leader 写 clog 日志，确认该分区合并是否走 SKIP Merge。 ```shell success to submit medium compaction clog(ret=0, this={ls_id:{id:1002}, tablet_id:{id:200002}}, medium_info={compaction_type:"MAJOR_COMPACTION", merge_reason:"NO_INC_DATA", medium_snapshot:1736501947272096000 ``` 2. 写 clog 时间点附近，同一 OBServer 下，该 Tablet 是否有转储释放 MemTable。 ```shell release_head_memtable_ (ob_tablet_memtable_mgr.cpp:822) [3650161][T1002_MINI_MERG][T1002][xxxxx-xxxxx-xxxxx-xxxxx] [lt=15] succeed to release head data memtable(ret=0, occupy_size=180355072, memtable={ObITabletMemtable:{ObITable:{this:0xc00ab42eac0, key:{tablet_id:{id:200002} ``` ## 问题原因 共享存储模式下，如果一个分区在合并前没有增量数据，那么该分区在合并时会走快速路径：Skip Merge，即直接通过旧 Major 拷贝出一个新 Major，然后完成合并。 合并前会由分区对应的 LS Leader 写 Medium Compaction Clog，并在写 clog 前判断该分区是否有增量数据： - 如果一个 Tablet 上既没有 MemTable，也没有 Mini/Minor SSTable，就认为该 Tablet 上不存在增量数据，则可以走 Skip Merge。 - 如果一个 Tablet 存在增量数据，但又走了 Skip Merge，则会导致增量数据没有写进 Major SSTable 中，合并后使用新 Major SSTable 查询，就会丢数据。 然而在判断 Tablet 上是否有 MemTable 时误用了错误的接口，应该用 **`ObTablet::get_memtables`** 接口，而不应该用 **`ObTablet:get_all_memtables`** 接口。使用 **`ObTablet::get_all_memtables`** 接口会导致在某些情况下 Tablet 看不到 MemTable，进而导致误判断。 ## 问题的风险及影响 **SN 模式不影响，只影响 SS 模式。该问题会导致业务丢数据**。 ## 影响租户 影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。 ## 影响版本 OceanBase 数据库企业版 V4.3.5 GA（oceanbase-4.3.5.0-100000122024123020）及之后版本。 ## 解决方法 升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V4.3.5 GA Hotfix2（oceanbase-4.3.5.0-100020012025012015）、V4.3.5 GA Hotfix3（oceanbase-4.3.5.0-100030012025020717）、V4.3.5 GA Hotfix4（oceanbase-4.3.5.0-100040012025021921）、V4.3.5 GA Hotfix5（oceanbase-4.3.5.0-100050012025022422）、V4.3.5 GA Hotfix6（oceanbase-4.3.5.0-100060022025031922）、V4.3.5 GA Hotfix7（oceanbase-4.3.5.0-100070012025040810）、V4.3.5 GA Hotfix8（oceanbase-4.3.5.0-100080012025052715）、V4.3.5 GA Hotfix9（oceanbase-4.3.5.0-100090012025063017）、V4.3.5 GA Hotfix10（oceanbase-4.3.5.0-100100032025071516）、V4.3.5 GA Hotfix11（oceanbase-4.3.5.0-100110012025072810）、V4.3.5 GA Hotfix12（oceanbase-4.3.5.0-100120012026011215）、V4.3.5 BP1（oceanbase-4.3.5.1-101000292025030623）。 ## 规避方式 无，尽快升级到带 Hotfix 版本。 Previous [执行读写 SQL 时写入限速可能导致转储慢，无法释放冻结的 MemTable 的原因和解决方法](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000002045134) Next [OceanBase 数据库 V4.2.1 BP7 版本转储报错 -4018 导致 clog 无法回收的原因和解决方法](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000001939898) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线