【 使用环境 】生产环境
【 OB or 其他组件 】
OBServer
【 使用版本 】
4.3.5.2
【问题描述】清晰明确描述问题
告警信息
查询checksum出错的tablet_id信息(LOB AUX TABLE:LOB 辅助表,系统自建的表,用于辅助实现 LOB 列)
根据data_table_id 查询到具体表(截取部分)
表结构如下,有一个列是lob字段
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接(右键跳转查看):
【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试,在发帖时输入 [@论坛小助手] 即可召唤小助手,欢迎试用!
论坛小助手
#3
针对您提到的 OBServer 租户合并失败并出现“checksum error in tablet replica checksum”错误(错误码 4103)的问题,可以使用 obdiag 工具来辅助诊断。这可能是由于数据一致性校验不通过导致的问题。首先推荐您进行日志采集,以便我们进一步分析具体原因。
日志采集场景: 合并问题
日志采集命令: obdiag gather scene run --scene=observer.compaction
请运行上述命令进行日志的采集,并将采集到的日志提供给我们,以便于更准确地定位问题。
另外,为了确定具体的问题,在此需要您提供一些信息:
- 当前 OceanBase 版本是多少?
- 能否提供更多关于租户配置的细节?
- 此次合并操作之前是否有过任何数据变更或维护操作?
- 该错误是否频繁发生?如果是,频率大概是多少?
- 系统当前是否有足够的资源(如磁盘空间、CPU、内存等)来进行合并操作?
感谢您的配合!
附上敏捷诊断工具 obdiag 使用帮助链接
淇铭
#4
SHOW VARIABLES like ‘version_comment’; 具体的版本信息查一下
使用obdiag收集一下合并失败前后半个小时的日志信息
obdiag gather log --from “2022-06-30 16:25:00” --to “2022-06-30 18:30:00”
–config obcluster.servers.nodes[0].ip=xx.xx.xx.1
–config obcluster.servers.nodes[1].ip=xx.xx.xx.xx.2
–config obcluster.servers.global.ssh_username=test
–config obcluster.servers.global.ssh_password=******
–config obcluster.servers.global.home_path=/home/admin/oceanbase
https://www.oceanbase.com/docs/common-obdiag-cn-1000000003892509
淇铭
#5
查询一下 看看是否合并报错
select * from __all_zone where name = “is_merge_error” or info = “ERROR”;
select * from __all_rootservice_event_history where module = “daily_merge” and event like “%merge_error%” order by gmt_create desc limit 1;
淇铭
#7
具体按照我发的信息 查一下 ob的版本具体信息也查一下
淇铭
#8
select * from __all_virtual_tablet_replica_checksum where tenant_id = 10xx and ls_id = 10xxand tablet_id = xxxx \G;