为了更快的定位您的问题，请提供以下信息，谢谢
【详述】get database read lock timeout, database=scm, timeout=3750ms
【背景】做过哪些操作？
【业务影响】
【是否存算分离】是
【StarRocks版本】3.3.4
【集群规模】例如：3fe（1 follower+2observer）+4be
【机器信息】8核32G
【表模型】例如：主键模型
【导入或者导出方式】debezium导入kafka，使用 Kafka connector导入starrocks
【联系方式】微信:bulolo
【附件】
2024-10-16 09:32:04,989 ERROR || WorkerSinkTask{id=sink-starrocks-crm-order-item-allots-cdc-0} Commit of offsets threw an unexpected exception for sequence number 35: null [org.apache.kafka.connect.runtime.WorkerSinkTask]
java.lang.RuntimeException: com.starrocks.data.load.stream.exception.StreamLoadFailException: Stream load failed because of error, db: scm, table: ods_crm_order_item_allots, label: -b0c7a7e1-9ded-45e8-8c65-3492bb25f2e2,
responseBody: {
“Status”: “TIMEOUT”,
“Message”: “get database read lock timeout, database=scm, timeout=3750ms”
}
errorLog: null
at com.starrocks.connector.kafka.StarRocksSinkTask.preCommit(StarRocksSinkTask.java:371)
at org.apache.kafka.connect.runtime.WorkerSinkTask.commitOffsets(WorkerSinkTask.java:411)
at org.apache.kafka.connect.runtime.WorkerSinkTask.commitOffsets(WorkerSinkTask.java:381)
at org.apache.kafka.connect.runtime.WorkerSinkTask.iteration(WorkerSinkTask.java:221)
at org.apache.kafka.connect.runtime.WorkerSinkTask.execute(WorkerSinkTask.java:206)
at org.apache.kafka.connect.runtime.WorkerTask.doRun(WorkerTask.java:204)
at org.apache.kafka.connect.runtime.WorkerTask.run(WorkerTask.java:259)
at org.apache.kafka.connect.runtime.isolation.Plugins.lambda$withClassLoader$1(Plugins.java:181)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
先改下be的配置
thrift_rpc_timeout_ms 默认是5000，可以改成60000。
这里外表占用锁时间长的问题在优化了
调下fe.conf
jdbc_meta_default_cache_enable=true
jdbc_meta_default_cache_expire_sec=60000
你好，我这也遇到相同的锁问题，请问你那边解决了吗？能分享下经验不
fe.info有slow lock的日志，上面会打印锁的原因
什么版本，没打堆栈吗？lock附近，新版本会打个堆栈
是3.2.4的版本
那应该会打堆栈
没看到啊，我刚找了下
fe.info 日志发下，要不先升级到3.2的最新版本看看？
一样的问题，和帖子里一样的处理方式就行，时间斟酌下
好的 感谢
thrift_rpc_timeout_ms 这个参数3.1之后移除了，有其他可替换参数吗
jdbc_meta_default_cache_enable=true
jdbc_meta_default_cache_expire_sec=60000 只改这两个
好的 感谢支持