写阻塞读 key is locked (backoff or cleanup) ，有什么缓解的方法？

erwadba · 2022 年10 月 31 日 03:20

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
【概述】场景 + 问题概述
查询论坛的文章。基本不会对应用造成影响。
但是应用程序上面会报类似的错误。有部分查询受到影响了。有什么缓解的方法？
Key is locked (will clean up) primary_lock: - TiDB - TiDB 的问答社区 (asktug.com)

[2022/10/31 09:48:26.307 +08:00] [INFO] [conn.go:1069] ["command dispatched failed"] [conn=19166671] [connInfo="id:19166671, addr:10.205.238.139:37336 status:10, collation:utf8_general_ci, user:prod_xx"] [command=Query] [status="inTxn:0, autocommit:1"] [sql="SELECT MIN(CheckPoint)-1,MAX(CheckPoint) FROM po_xxx_01 WHERE CheckPoint>3267009"] [txn_mode=PESSIMISTIC] [err="other error: key is locked (backoff or cleanup) primary_lock: 7480000000000000FF5F69800000000000000503800000000031D63E lock_version: 437041471491670093 key: 7480000000000000FF5F69800000000000000503800000000031D9C2 lock_ttl: 3000 txn_size: 2 use_async_commit: true min_commit_ts: 437041471491670095\ngithub.com/pingcap/tidb/store/copr.(*copIteratorWorker).handleCopResponse\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/store/copr/coprocessor.go:913\ngithub.com/pingcap/tidb/store/copr.(*copIteratorWorker).handleTaskOnce\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/store/copr/coprocessor.go:755\ngithub.com/pingcap/tidb/store/copr.(*copIteratorWorker).handleTask\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/store/copr/coprocessor.go:645\ngithub.com/pingcap/tidb/store/copr.(*copIteratorWorker).run\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/store/copr/coprocessor.go:382\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1371"]

【背景】做过哪些操作

【现象】业务和数据库现象

【问题】当前遇到的问题

【业务影响】

【TiDB 版本】

tidb_version(): Release Version: v5.3.0
Edition: Community
Git Commit Hash: 4a1b2e9fe5b5afb1068c56de47adb07098d768d6
Git Branch: heads/refs/tags/v5.3.0
UTC Build Time: 2021-11-24 13:32:39
GoVersion: go1.16.4
Race Enabled: false
TiKV Min Version: v3.0.0-60965b006877ca7234adaced7890d7b029ed1306
Check Table Before Drop: false
1 row in set (0.00 sec)

【应用软件及版本】

【附件】相关日志及配置信息

TiUP Cluster Display 信息
TiUP CLuster Edit config 信息

监控（https://metricstool.pingcap.com/)

TiDB-Overview Grafana监控
TiDB Grafana 监控
TiKV Grafana 监控
PD Grafana 监控
对应模块日志（包含问题前后 1 小时日志）

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

xfworld · 2022 年10 月 31 日 05:55

事务执行超时了，减少事务操作的内容，或者分段执行，都可以有效减轻这个问题

近墨者zyl · 2022 年10 月 31 日 06:37

业务读写冲突严重，才会报这个错误
key is locked 读写冲突，读请求碰到还未提交的数据，需要等待其提交之后才能读。少量这个错误对业务无影响，大量出现这个错误说明业务读写冲突比较严重。

解决方法：改为悲观锁模式，不要使用乐观锁

近墨者zyl · 2022 年10 月 31 日 06:41

https://docs.pingcap.com/zh/tidb/stable/troubleshoot-lock-conflicts#读写冲突
看看这个文档，会帮助你解决问题

erwadba · 2022 年11 月 1 日 00:33

已经使用的悲观锁模式

erwadba · 2022 年11 月 1 日 02:16

个人猜测大致原因如下：
可能是下面原因引起的。目前该集群设置了set global tidb_replica_read=‘leader-and-follower’。
follower节点上面可能由于还存在着primary key的信息导致的。查看报错的tidb.log日志中storeAddr显示的follower的地址。
修改参数set global tidb_replica_read='leader‘，重启tidb节点之后。告警消失。

报错日志error="other error: key is locked (backoff or cleanup) 。中storeAddr=xx.xx.xx.xx显示的正好是follower的地址。
[2022/11/01 08:42:02.985 +08:00] [WARN] [coprocessor.go:914] ["other error"] [conn=8233] [txnStartTS=437063076535336968] [regionID=22127261] [storeAddr=10.15
0.xx.xx:20160] [error="other error: key is locked (backoff or cleanup) primary_lock: 7480000000000001515F698000000000000004038000000000432DF8 lock_version: 4
37063076522229789 key: 7480000000000001515F698000000000000004038000000000432DFC lock_ttl: 3008 txn_size: 2 use_async_commit: true min_commit_ts: 437063076522
229790"]
[2022/11/01 08:42:03.006 +08:00] [INFO] [conn.go:1069] ["command dispatched failed"] [conn=8233] [connInfo="id:8233, addr:10.205.xx.xx:38718 status:10, col
lation:utf8_general_ci, user:prod_xx"] [command=Query] [status="inTxn:0, autocommit:1"] [sql="SELECT MIN(CheckPoint)-1,MAX(CheckPoint) FROM po_xx_0
2 WHERE CheckPoint>4402683"] [txn_mode=PESSIMISTIC] [err="other error: key is locked (backoff or cleanup) primary_lock: 7480000000000001515F69800000000000000
4038000000000432DF8 lock_version: 437063076522229789 key: 7480000000000001515F698000000000000004038000000000432DFC lock_ttl: 3008 txn_size: 2 use_async_commi
t: true min_commit_ts: 437063076522229790\ngithub.com/pingcap/tidb/store/copr.(*copIteratorWorker).handleCopResponse\n\t/home/jenkins/agent/workspace/optimiz
ation-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/store/copr/coprocessor.go:913\ngithub.com/pingcap/tidb/store/copr.(*copIteratorWorker).handleTaskOn
ce\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/store/copr/coprocessor.go:755\ngithub.com/pingcap/tidb/s
tore/copr.(*copIteratorWorker).handleTask\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tidb/store/copr/coproc
essor.go:645\ngithub.com/pingcap/tidb/store/copr.(*copIteratorWorker).run\n\t/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.co
m/pingcap/tidb/store/copr/coprocessor.go:382\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1371"]
[2022/11/01 08:43:56.124 +08:00] [WARN] [coprocessor.go:914] ["other error"] [conn=8233] [txnStartTS=437063106183823366] [regionID=22083063] [storeAddr=10.15
0.xx.xx:20160] [error="other error: key is locked (backoff or cleanup) primary_lock: 7480000000000002585F69800000000000000203800000000024FD73 lock_version: 4
37063106183823365 key: 7480000000000002585F69800000000000000203800000000024FDA7 lock_ttl: 3003 txn_size: 3 use_async_commit: true min_commit_ts: 437063106183
823366"]
[2022/11/01 08:43:56.124 +08:00] [WARN] [coprocessor.go:914] ["other error"] [conn=8233] [txnStartTS=437063106183823366] [regionID=22083063] [storeAddr=10.15
0.xx.xx:20160] [error="other error: key is locked (backoff or cleanup) primary_lock: 7480000000000002585F69800000000000000203800000000024FD73 lock_version: 4
37063106183823365 key: 7480000000000002585F69800000000000000203800000000024FDA7 lock_ttl: 3003 txn_size: 3 use_async_commit: true min_commit_ts: 437063106183
823366"]

h5n1 · 2022 年11 月 2 日 01:57

resovle lock发生在leader上，通过raft同步清理日志。GC时会resolve lock清理gc safepoint前的锁，leader上有访问时发现secodary未清理也会resolve lock，猜测如果leader上未清理的secondary lock有较长时间未访问可能导致无法及时处理，也就无法同步到follower。对于TP类实时业务还是访问leader ，哪些非实时的比如抽数，可以考虑单独设置一个tidb 可以查follower

胡杨树旁 · 2022 年11 月 11 日 09:15

不是说有MVCC 机制，保证了读和写不冲突，这里怎么会出现读写冲突呢？

Raymond · 2022 年11 月 11 日 14:08

RR模式下，为了防止出现幻读，会有读写冲突,RC不会有读写冲突

erwadba · 2022 年11 月 12 日 09:30

本来想通过参数设置。分担leader节点的压力。看来是行不通。
看最新的代码里面。tidb_replica_read=这参数有多个选项(closest-replicas/closest-adaptive)。估计也会存在这种问题
https://github.com/pingcap/tidb/blob/ad4d43219ab66c67eb54ea2aad709bd5d8944b12/sessionctx/variable/sysvar.go#L1623

alfred · 2022 年11 月 13 日 03:14

https://docs.pingcap.com/zh/tidb/stable/follower-read 是在SI隔离级别下

system · 2023 年1 月 12 日 03:15

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。