【 使用环境 】测试环境
【 OB or 其他组件 】
通过obd部署的metadb4.2.5.2，ocp，obproxy，使用3个节点
【 使用版本 】
【问题描述】清晰明确描述问题
目前发现obproxy_err.log日志持续刷如下日志，符合预期吗
2026-03-17 11:32:54.019120,undefined,metadb:ocp_meta:meta_database,OB_MYSQL,DISTRIBUTED_LOCK,distributed_lock,OB_MYSQL_COM_QUERY,INSERT,failed,1062,INSERT INTO DISTRIBUTED_LOCK (LOCK_KEY%2C CLIENT_ID%2C CREATE_TIME%2C EXPIRE_TIME) VALUES (‘shading-lock-alarm-detect-by-rule’%2C ‘xxx:8080’%2C CURRENT_TIMESTAMP%2C TIMESTAMPADD(SECOND%2C 10%2C CURRENT_TIMESTAMP)),508us,159us,0us,348us,Y0-00002B39279423D0,YB420A72081F-00064EB5004F8F0E-0-0,xxx:29350,0,xxx:2881,Duplicate entry ‘shading-lock-alarm-detect-by-rule’ for key ‘PRIMARY’,YB420A72081F-00064EB5004F8F0E-0-0
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：
【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！
论坛小助手
#3
日志采集场景: SQL 执行出错
日志采集命令: obdiag gather scene run --scene=observer.sql_err --env “{db_connect=’-h<主机IP> -P<端口> -u<用户名>@<租户名> -p<密码> -D<数据库名>’, trace_id=’<trace_id>’}”
为了更好地帮助您解决这个问题，建议您使用上述命令采集日志并提供给我们。同时，请回答以下几个问题，以便我们能够更准确地定位问题：
- 您当前使用的 OceanBase 版本是什么？
- 这些错误日志出现的具体时间和频率是怎样的？
- 插入
DISTRIBUTED_LOCK 表的操作是哪个应用或进程发起的？
- 能否提供出现问题前后的一些操作记录或变更记录？
- 当前 metadb 集群的负载情况如何？是否有异常高的读写请求？
- 能否提供
DISTRIBUTED_LOCK 表的结构定义？
以上信息将有助于我们进一步分析问题的原因。谢谢！
附上敏捷诊断工具 obdiag 使用帮助链接
ocp 访问正常，就是metadb集群的所属的obproxy组件错误日志obproxy_err.log持续刷1062报错，冲突的key还不是同一个
Duplicate entry ‘shading-lock-metric-collect’ for key ‘PRIMARY’
Duplicate entry ‘shading-lock-alarm-detect-by-target’ for key ‘PRIMARY’
Duplicate entry ‘shading-lock-metric-collect’ for key ‘PRIMARY’
辞霜
#6
根据这个trace id到ob日志中grep一下看看00064EB5004F8F0E
根据trace_id过滤不到日志，很奇怪（已经取最新的trace_id了）
另外补充下，通过查看obproxy_error.log日志，定位到报错的来源程序是ocp-server.jar，通过obd把另外两个ocp服务停掉后，只留了单节点ocp，obproxy_error.log中也是会刷上述报错。和多个节点ocp应该没有关系
想咨询下，这个表meta_database.DISTRIBUTED LOCK写入失败会有什么影响，公开文档没有相关介绍，这块逻辑是怎样的啊
辞霜
#10
这个报错表示OCP 分布式锁机制的 预期行为，表示当前节点（xxx:8080 ）尝试获取告警检测锁时，锁已被其他节点持有。这类日志在多节点 OCP 部署中会频繁出现，属于正常现象，无需处理
1 个赞
