ob社区版bug确认

【 使用环境 】生产环境
【 OB or 其他组件 】observer社区版
【 使用版本 】OceanBase 构建版本号:4.2.5.7-107010012026030415
【问题描述】observer频繁宕机
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接(右键跳转查看):

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试,在发帖时输入 [@论坛小助手] 即可召唤小助手,欢迎试用!

这个问题之前在ob企业版出现过,已经确认了是一个已知bug,想确认下 在社区版 有没有这个bug ,在哪个版本修复过。

1、问题现象
observer 执行非向量化hash join,join类型为LEFT OUFER/LEFT ANTI,并且左边走了nestloop模式多轮处理,访问了野指针导致crash。

2、问题根因
非向量化 Left Outer Join 在内存不足触发落盘后降级为 Nest Loop(NLJ)分块执行,多轮 chunk 循环中,上一轮 FILL_LEFT 阶段结束后遗留的 cur_tuple_ 指针未被清空,chunk 复用释放旧内存后,新一轮 PROBE 阶段 read_hashrow_normal() 解引用该脏指针导致 OBServer Crash。

3、触发条件(同时满足)
(1)非向量化执行路径-PHY_HASH_JOIN
(2)Left Outer Join
(3)数据量大 + 内存不足 → 落盘
(4)执行模式为 NLJ 分块(非 shared hash join)
(5)左表 join key 相同值多(倾斜)

4、诊断方法
(1)查看是否走的hash join非向量化路径
(2)观察堆栈是否类似
oceanbase::sql::ObHashJoinOp::read_hashrow_normal() at 0_cxx.cxx:?
oceanbase::sql::ObHashJoinOp::next() at 0_cxx.cxx:?
oceanbase::sql::ObHashJoinOp::inner_get_next_row() at 0_cxx.cxx:?
oceanbase::sql::ObOperator::get_next_row() at ??:?
oceanbase::sql::ObResultSet::get_next_row(oceanbase::common::ObNewRow const*&) at ??:?
oceanbase::observer::ObQueryDriver::response_query_result(oceanbase::sql::ObResultSet&, bool, bool, bool&, long) at 0_cxx.cxx:?
oceanbase::observer::ObSyncPlanDriver::response_result(oceanbase::observer::ObMySQLResultSet&) at 0_cxx.cxx:?
oceanbase::observer::ObMPQuery::process_single_stmt(oceanbase::sql::ObMultiStmtItem const&, oceanbase::sql::ObSQLSessionInfo&, bool, bool, bool&, bool&) at 0_cxx.cxx:?
oceanbase::observer::ObMPQuery::process() at ??:?
oceanbase::omt::ObWorkerProcessor::process(oceanbase::rpc::ObRequest&) at 0_cxx.cxx:?
oceanbase::omt::ObThWorker::worker(long&, long&, int&) at 0_cxx.cxx:?
non-virtual thunk to oceanbase::omt::ObThWorker::run(long) at 0_cxx.cxx:?
oceanbase::lib::Thread::__th_start(void*) at 0_cxx.cxx:?
                                                             
5、解决方案
(1)彻底解决
升级版本425bp7 hotfix11 & 425bp8
(2)规避方法
调整租户级配置项, 关闭hash join落盘中NLJ模式 alter system set _enable_hash_join_processor = 6;
(3)规避方法影响与预案
极少数原本依赖 NLJ 的倾斜场景可能报错,此时可通过扩租户内存或调大 ob_sql_work_area_percentage(默认 3%,可调至 5~10%)让查询不落盘、绕开降级路径。

6、影响范围
(1)影响版本
 421及之后版本
(2)修复版本
421bp11 hotfix6/425bp7 hotfix11/425bp8/435BP6/442BP1及之上版本

根据您的描述,您遇到的是observer频繁宕机的问题。在处理这类问题时,我们首先推荐使用obdiag工具进行日志采集,以帮助分析具体的宕机原因。关于您提到的是否已知bug以及修复版本的信息,这需要基于具体的错误日志来判断。请先按照以下步骤操作,之后我们可以进一步讨论具体的原因及可能的解决方案。

日志采集场景: observer无故重启
日志采集命令: obdiag gather scene run --scene=observer.restart

执行上述命令后,请将收集到的日志文件压缩包提供给我们。这样能够使我们更准确地定位问题发生的原因,并告知该问题是否为已知问题以及在哪一版本中被解决。

此外,为了能更好地帮助您解决问题,我还需要了解一些额外的信息:

  1. 您当前使用的OceanBase社区版的具体版本号是多少?
  2. 这个问题是在什么情况下发生的?(例如:执行特定操作后、升级后、或者没有明显的触发因素)
  3. 在observer重启前后,观察到了哪些异常现象或收到了什么样的错误信息?
  4. 您的操作系统和硬件配置是怎样的?

以上信息有助于我们更快速准确地定位问题所在。

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