1. 前言
OceanBase数据库的存储引擎以 LSM-Tree 架构为基础,区分静态基线数据(存储在只读SSTable)和动态增量数据(存储在可读写MemTable)。其中 SSTable 是只读的,一旦生成就不再被修改,存储于磁盘;MemTable 支持读写,存储于内存。当进行数据库的DML操作时,如插入、更新或删除,这些操作首先被写入MemTable。随着MemTable中的数据量逐渐增大到一定规模时,这些数据会被转储到磁盘上,形成SSTable。在进行查询时,系统需要同时对SSTable和MemTable进行查询操作,然后将这两个查询结果进行归并,最终将归并后的查询结果返回给SQL层。此外,为了避免对基线数据的随机读,OceanBase还在内存中实现了Block Cache和Row Cache。
当内存的增量数据达到一定规模的时候,会触发增量数据和基线数据的合并,将增量数据写入磁盘。此外,系统还会在每天晚上的空闲时段自动进行每日合并操作。
2. 视图介绍
视图 | 功能 |
GV$OB_SSTABLES | 展示每台OBServer上各分区下的MEMTable和SSTable信息 |
CDB_OB_MAJOR_COMPACTION | 展示所有租户的全局合并信息 |
GV$OB_COMPACTION_PROGRESS | 展示租户的Server级compaction进度信息 |
GV$OB_TABLET_COMPACTION_PROGRESS | 展示tablet级的compaction进度信息 |
GV$OB_TABLET_COMPACTION_HISTORY | 展示tablet级的compaction历史信息 |
GV$OB_COMPACTION_DIAGNOSE_INFO | 展示compaction诊断信息 |
GV$OB_COMPACTION_SUGGESTIONS | 展示compaction建议信息 |
3.如何借助视图排查问题
3.1 合并/Major Merge
1)通过CDB_OB_MAJOR_COMPACTION
查看当前集群的合并情况,如果STATUS处于COMPACTING状态,说明正在执行合并;
select * from CDB_OB_MAJOR_COMPACTION;
2)通过GV$OB_COMPACTION_PROGRESS
查询server级别的合并进度,可以看到当前是否有合并任务(STATUS="NODE_RUNNING"
),未完成的tablet数量(UNFINISHED_TABLET_COUNT
)等信息.
select * from GV$OB_COMPACTION_PROGRESS where STATUS="NODE_RUNNING";
更具体来说:
select * from GV$OB_COMPACTION_PROGRESS where tenant_id = xx and compaction_scn = xxx and STATUS != "FINISH";
3)通过GV$OB_TABLET_COMPACTION_PROGRESS
查询tablet级别的合并进度,可以看到未完成的数据量(UNFINISHED_DATA_SIZE
),预期完成时间(ESTIMATED_FINISH_TIME
)等信息
select * from GV$OB_TABLET_COMPACTION_PROGRESS;
4)对于未出现在tablet合并进度中的tablet或者长时间未完成的tablet,可以通过GV$OB_COMPACTION_DIAGNOSE_INFO
进行诊断,查看是否有异常情况出现
select * from GV$OB_COMPACTION_DIAGNOSE_INFO;
注意事项
合并是否卡住没有一个硬性指标,但通常可以检查CDB_OB_MAJOR_COMPACTION
表中是否存在租户的STATUS长时间处于COMPACTING状态(这里的长时间需要根据数据量和经验判断,无脑判断的话36小时)。
另一个判断方式是检查GV$OB_COMPACTION_PROGRESS
中STATUS="NODE_RUNNING"
的合并任务,是否长时间没有更新过UNFINISHED_TABLET_COUNT
。
排查步骤
首先无脑查GV$OB_COMPACTION_DIAGNOSE_INFO
视图,如果有信息则根据第三小节的具体内容判断原因。
3.2 转储/Mini Merge
1)通过GV$OB_SSTABLES
查看是否存在冻结的MEMTable
select * from GV$OB_SSTABLES where table_type = "MEMTABLE" and is_active = "NO";
2)通过GV$OB_TABLET_COMPACTION_PROGRESS
查询tablet级别的合并进度,可以看到未完成的数据量(UNFINISHED_DATA_SIZE
),预期完成时间(ESTIMATED_FINISH_TIME
)等信息
select * from GV$OB_TABLET_COMPACTION_PROGRESS;
4)对于未出现在tablet合并进度中的tablet或者长时间未完成的tablet,可以通过GV$OB_COMPACTION_DIAGNOSE_INFO
进行诊断,查看是否有异常情况出现
select * from GV$OB_COMPACTION_DIAGNOSE_INFO;
3.3 诊断视图GV$OB_COMPACTION_DIAGNOSE_INFO指南
概念:在Compaction出现异常的情况下,OBServer会收集相关信息用于原因诊断。
用法:select * from GV$OB_COMPACTION_DIAGNOSE_INFO;
首先通过STATUS
来过滤信息的严重程度,从低到高:
SPECIAL
:用来输出一些相同问题的tablet数量RS_UNCOMPACTED
:不一定存在异常。说明还存在tablet版本尚未推高至当前合并版本号,可以先通过GV$OB_COMPACTION_PROGRESS
判断是否处于正常合并进行的状态。如果还有RUNNING
的合并,则大概率是合并任务的问题。NOT_SCHEDULE
:表示compaction长时间未被调度。比较常见的是出现在follow上,由于medium info的同步落后导致的合并未调度;以及由于dag数量超限导致的MINI未调度。FAILED
:表示出现一些明显的异常。
具体的问题主要通过DIAGNOSE_INFO
字段来描述。
4.如何借助obdiag来分析合并问题
obdiag官网文档参见: OceanBase分布式数据库-海量数据 笔笔算数
使用 obdiag rca 命令可帮助 OceanBase 数据库相关的诊断信息分析,目前支持对 OceanBase 的异常场景进行分析,找出可能导致问题的原因。
obdiag rca list # 列出所有的根因分析场景
obdiag rca run --scene=<scene_name> #执行具体场景的根因分析
scene_name
包含如下:
- disconnection:一键断连诊断,基于obproxy的诊断日志。
- major_hold: 一键卡合并诊断。
- lock_conflict: 一键锁冲突诊断。
示例:分析卡合并场景
obdiag rca run --scene=major_hold
5.总结
6. 附录
- obdiag 官方文档: OceanBase分布式数据库-海量数据 笔笔算数
- obdiag github地址: GitHub - oceanbase/oceanbase-diagnostic-tool: OceanBase Diagnostic Tool is designed to help OceanBase users quickly gather necessary information and analyze the cause of the problem.
第一篇 | 如何修炼成“神医”——《OceanBase诊断系列》之一 |
第二篇 | 走进SQL审计视图——《OceanBase诊断系列》之二 |
第三篇 | 一键操作敏捷诊断工具obdiag收集诊断信息实践——《OceanBase诊断系列》之三 |
第四篇 | 一键操作敏捷诊断工具obdiag分析OB集群日志设计与实践——《OceanBase诊断系列》之四 |
第五篇 | 专为OceanBase打造的巡检工具已推出!给OceanBase进行一次体检吧——《OceanBase诊断系列》之五 |
第六篇 | obdiag帮你读懂全链路诊断日志——《OceanBase诊断系列》之六 |
第七篇 | 如何排查合并问题——《OceanBase诊断系列》之七 |