从aOceanBase 4.4.2 TLS 版本observer节点 crash,obdiag定位到T1002_TTL_DELTE 线程,求排查思路 继续讨论:
【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
【 使用版本 】
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接(右键跳转查看):
【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试,在发帖时输入 [@论坛小助手 ] 即可召唤小助手,欢迎试用!
1 个赞
论坛小助手
2026 年4 月 8 日 00:57
#3
针对您描述的问题,可以使用 obdiag 工具进行日志采集,特别是关注与崩溃相关的线程 T1002_TTL_DELETE。以下是具体的步骤和命令:
日志采集场景
日志采集场景: observer无故重启
日志采集命令:
obdiag gather scene run --scene=observer.restart
根因分析场景
由于您已经定位到了具体的线程 T1002_TTL_DELETE,我们可以尝试进行根因分析,但目前 obdiag 没有专门针对这个线程的根因分析场景。您可以先进行日志采集,然后根据日志内容进一步分析。
推荐步骤
执行日志采集命令 :
obdiag gather scene run --scene=observer.restart
这个命令会收集与 observer 无故重启相关的日志信息,包括但不限于系统日志、core dump 文件、进程堆栈等。
提供日志压缩包 :
请将采集到的日志压缩包提供给我们,以便我们进一步分析问题。
需要您提供的更多信息
为了更好地帮助您定位问题,请提供以下信息:
发生崩溃的具体时间 :
这将有助于我们在日志中找到相关的时间段,更快地定位问题。
系统环境信息 :
包括操作系统版本、OceanBase 版本、硬件配置等。
崩溃前的操作 :
在崩溃前是否有特定的操作或负载,例如执行了某些 SQL 语句或进行了数据导入导出操作。
相关日志片段 :
如果您已经有了一些日志片段,可以提前提供给我们,这将有助于我们更快地分析问题。
希望这些信息能帮助您解决问题,如果您有任何其他问题或需要进一步的帮助,请随时联系我们。
附上敏捷诊断工具 obdiag 使用帮助链接
2 个赞
没有,就是在后台执行ttl任务时候发生了,期间也没用数据导入操作,crash的时间和ttl任务的开始时间对的上
2 个赞
文中提到的OceanBase问题很常见,通过优化obdiag和调整scene配置,通常可以解决。
1 个赞
辞霜
2026 年4 月 8 日 09:41
#14
442详细版本号提供一下
select build_version from dba_ob_servers;
根据版本号,在镜像库下载同版本debuginfo包使用rpm安装,查看安装路径拷贝到bin目录下
https://mirrors.oceanbase.com/community/stable/
再使用gdb打印一份
cd /path/observer/bin
gdb observer /path/core_file
set logging file /path/gdb.txt
set logging on
set pagination off
set print pretty on
set print elements 0
bt
bt full
info r
info thread
set logging off
quit
1 个赞
辞霜
2026 年4 月 8 日 10:22
#17
参考上面的步骤提供一下详细版本号,使用debuginfo包再跑一遍gdb
4.4.2.0_100000032026021017-e859d1b9c9a6d11d856f4fed5b6385f1a6795820
gdb.txt (1.6 MB)
机器系统是Ubuntu 24.04 LTS