【 使用环境 】生产环境
【 OB or 其他组件 】OB
【 使用版本 】4.2.5.7
【问题描述】data目录存在多个core文件，是否存在隐性分险，需要分析其原因
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！
1 个赞
根据您的描述，OceanBase 集群在生产环境中出现了多次core文件生成的情况，尽管进程能够自动拉起，但这种情况依然可能表明系统中存在潜在的问题或风险。使用 obdiag 工具可以帮助您收集必要的诊断信息，以进一步分析这些core文件背后的具体原因。
日志采集场景: 未能明确问题的场景
在这种情况下，因为具体的触发原因还不太明确，我们推荐从基础层面进行更广泛的日志采集。
-
日志采集命令:
obdiag gather scene run --scene=observer.unknown
这条命令将帮助收集一系列有助于诊断集群状态的基础信息，包括但不限于配置、性能指标以及最近的日志记录等，这对于我们理解产生core文件的原因非常有帮助。
请按照上述指令执行并准备好收集到的日志压缩包。此外，为了更好地定位问题所在，还需要您提供以下几方面的详情：
- 发生core文件时是否有执行特定操作或SQL语句？如果有，请尽量详细说明相关情况。
- 在生成core文件前后的时间段内，观察到服务器资源（CPU、内存、磁盘I/O）的使用状况如何？
- 您是否已经尝试过查看core文件内容？如果方便的话，能否分享一些初步发现或异常提示？
- 这个现象是在所有节点上都会出现还是仅限于某些特定的Observer节点？
- 最近一次对集群执行的操作（例如升级、参数调整等）是什么时候，做了哪些更改？
有了这些附加信息后，我们将能够更加准确地判断问题所在，并为您提供针对性的建议。
附上敏捷诊断工具 obdiag 使用帮助链接
1 个赞
老师，目前看都是6月份之前发生的core，今天集中发生在4月10日 和5月8日/11日，observer.log肯定都不在了，core文件都在，请问可以只提供core文件么
1 个赞
你可以先把core dump解析一下 看看 是否能分析出原因
1 个赞
老师，有解析core的相关文档么，我先试着解析下看看
1 个赞
1.安装 debuginfo
请安装和ob匹配的debuginfo包下载地址为：oceanbase-community-stable-el-7-x86_64安装包下载_开源镜像站-阿里云
rpm2cpio oceanbase-debuginfo-xxx.el7.x86_64.rpm | cpio -div
将解压出的observer.debug 文件拷贝进observer目录，默认为/home/admin/oceanbase/bin目录
2.升级gcc到最新：
sudo yum -y install gcc
3.安装texinfo包：
sudo yum install texinfo
4.安装gdb 9.1
wget https://ftp.gnu.org/gnu/gdb/gdb-9.1.tar.gz
tar -zxvf gdb-9.1.tar.gz
cd gdb-9.1.tar.gz
mkdir build
cd build
…/configure
make
make install
cp gdb/gdb /usr/bin
5. 获取gdb output信息
cd /path/observer/bin
gdb observer /path/core_file
–进入到 gdb 交互提示符后
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 个赞
老师，请问这个core文件是可以拿到任意有安装同版本的observer下分析么，是不是不依赖于当前OBserver，只是需要有/home/admin/oceanbase/bin目录 就行
1 个赞
可以在相同版本的observer下分析 如果环境允许尽量在当前环境下 跑一下
1 个赞