【使用版本】OceanBase 社区版 V4.2.x
【问题描述】
- 每日合并默认走全量还是增量？什么条件下会自动退化为全量合并？
- 合并期间查询读到的是什么状态的数据（是否读一致性快照）？会不会出现明显的 RT 抖动，还是基本无感？
- 如果一次性批量导入大量历史数据，是手动触发合并比较好，还是等调度自动跑？手动 major freeze 有哪些风险（比如和日常合并撞车）？
- 从视图上怎么观察一次合并的进度和是否卡住？
实验考试里有「转储与合并」这一题，想借这个问题把操作和原理一起搞清楚。
1 个赞
增量合并与全量合并的选择场景
- 增量合并：适用于日常数据写入较为频繁，且每次更新的数据量相对较小的场景。增量合并的优势在于其可以显著减少不必要的 IO 操作，通过重用未修改的数据块来提高合并效率，从而降低对系统性能的影响。这种合并方式在 OceanBase 数据库中是默认开启的，并且在大多数情况下都能满足需求。
- 全量合并：当发生大规模的数据变更，例如一次性导入大量历史数据或进行表结构重大调整时，采用全量合并可以确保所有数据的一致性和完整性。全量合并会重新生成所有的 SSTable 文件，虽然处理时间较长且消耗资源较多，但能有效清理旧版本数据，为后续操作提供干净的基础。
合并期间对在线业务的影响
- 在执行合并的过程中，OceanBase 会尽量保证读取操作的一致性快照视图。这意味着查询将基于某个一致性的全局快照进行，避免了读取到不完整或正在被修改中的数据。
- 对于实时响应时间（RT）而言，合并活动通常不会导致显著抖动。这是因为大部分读取请求可以直接访问最新的 SSTable 而无需等待合并完成。但是，在合并刚刚开始或者接近结束时，由于可能涉及到大量的磁盘 I/O 和内存使用，极少数情况下可能会观察到短暂的服务延迟增加。
每日合并默认走全量还是增量？什么条件下会自动退化为全量合并？
- 默认情况下，每日合并采取的是增量合并策略。
- 如果遇到以下几种情况之一，系统会自动切换至全量合并：
- 当需要清理过期的旧版本数据时。
- 遇到特定的 Schema 更改事件后。
- 手动设置了
default_progressive_merge_num参数值为 1 或更大数值时。
如果一次性批量导入大量历史数据，手动触发合并还是等调度自动跑？
- 对于大批量的历史数据导入，推荐手动触发一次合并 (
ALTER SYSTEM MAJOR FREEZE;) 以尽快整合这些新加入的数据。这样可以更早地释放由导入操作产生的临时空间，并改善整体查询性能。 - 手动发起 major freeze 存在潜在风险，主要是如果与预定的定时合并任务同时运行，则可能导致额外的资源竞争，影响数据库稳定性。因此建议选择在网络和系统负载较低的时间段执行此类操作。
从视图上怎么观察一次合并的进度和是否卡住？
可以通过查询 oceanbase.CDB_OB_ZONE_MAJOR_COMPACTION 视图来监控当前的合并状态。特别关注 STATUS 列，其可能包含以下几种状态：
-
IDLE: 表示没有正在进行中的合并。 -
COMPACTING: 表示正处于合并过程中。 -
VERIFYING: 正在校验 Checksum 中。
此外，还可以检查 LAST_FINISH_TIME 字段了解上次成功合并的时间点，以及 START_TIME 获取本次合并开始的具体时间。如果发现长时间处于非 IDLE 状态，可能表明合并遇到了问题，需进一步排查原因。
文档片段标题: OceanBase 数据库性能的影响因素 → 合并与统计信息收集 → 合并
文档片段标题: 合并相关参数说明如下表所示
文档片段标题: 本节主要介绍合并的分类、状态及压缩算法
文档片段标题: * 转储
检索到的文档如下:
2 个赞
从备考角度记一个判断口诀会更顺：日常小量写入走增量，批量导入或大范围结构调整再考虑全量，手动 major freeze 尽量避开业务高峰和系统自带的合并窗口。判断是不是卡住时，先看合并状态视图里是正在合并还是校验，再结合开始时间和上次完成时间，别只看磁盘 IO 高就下结论。