cubt
#1
【 使用环境 】
测试环境
【 OB 】
【 使用版本 】
OceanBase_CE 4.1.0.2
【问题描述】
1、 ocp配置了凌晨 )2:00 定时合并,早上发现一直可在 99.39%
2、查看告警看到合并失败的相关信息
3、发现162 这台服务器上日志已经没有凌晨的日志了
4、实际并没有配置syslog的个数
需求:
1、为什么我这在没有清理日志的配置情况下晚上的日志没了
2、在缺失日志无法分析的情况下,如何推荐合并操作,让合并完成
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试,在发帖时输入 [@论坛小助手] 即可召唤小助手,欢迎试用!
1 个赞
论坛小助手
#3
推荐使用 obdiag 工具进行日志采集,并且将采集到的日志提供给我们以便确认问题所在。
日志采集场景: 合并问题
日志采集命令: obdiag gather scene run --scene=observer.compaction
另外,为了确定具体的问题,在此需要您提供一些信息:
- 合并任务失败的具体错误信息是什么?
- 能否查看一下 162 服务器上定时合并任务的配置情况?
- 162 服务器上的日志目录是否有足够的磁盘空间?
- 是否有其他异常日志或报警信息?如果有,请提供具体的错误信息。
- 162 服务器上的定时合并任务之前是否正常工作过?
请根据以上信息采集日志并提供进一步的详细信息,以便我们能够更准确地定位问题。
附上敏捷诊断工具 obdiag 使用帮助链接
1 个赞
cubt
#4
因为测试环境,目录是非标准化的,直接都安装在了 根目录下
1 个赞
辞霜
#5
4.1版本太老了当前都不维护了优先选择升级吧。查询下
CDB_OB_MAJOR_COMPACTION 租户的全局合并信息
GV$OB_COMPACTION_DIAGNOSE_INFO 合并诊断信息
https://www.oceanbase.com/docs/common-oceanbase-database-cn-10000000001699163
1 个赞
cubt
#6
看到compaction类型都是medium的,我这个场景下如何让这个合并先完成,不然后面的操作受到影响了
1 个赞
辞霜
#8
把diagnose info中的trace id日志提取一下
1 个赞
cubt
#9
1 个赞
辞霜
#12
换节点查询下看看,错误还在 日志不应该没了。
并且查询下message日志,看日志是宏块存在问题
1 个赞
cubt
#13
目前看都没过滤出来,我看你给那个trace id对应的 tablet id 是 419,我是不是取现在419的 trace 过滤就行
1 个赞
cubt
#17
目前 tablet_id 419的trace 发生了变化,我基于新的 trace 进行的过滤YB420ABA3FA2-00063A6B5C1A9D6C-0-0
三个节点的 trace log 里都没过滤出这个trace,通过grep YB420ABA3FA2-00063A6B5C1A9D6C-0-0 * > /root/YB420ABA3FA2-00063A6B5C1A9D6C-0-0.log 获取了一个新的日志
YB420ABA3FA2-00063A6B5C1A9D6C-0-0.log (224.2 KB)
1 个赞
辞霜
#20
看日志是有个宏块问题,有可能是机器硬件故障。临时修复暂时没有,建议备份迁移走该集群吧,4.1版本已经很久前就不维护了。
1 个赞