一次 meet_lock 告警异常处理过程

1. TiKV-Detail>Coprocessor Overview

或者通过 Prometheus 获取指标数据

sum(rate(tikv_coprocessor_request_error[10m])) by (reason)

2. TiDB>KV Errors

指标解释:

  • regionMiss:Region缺失
  • txnLock:代表出现了写冲突
  • tikvLockFast:代表出现了读写冲突

通过监控可以看到写冲突并不高,而且也没有读写冲突。那么为什么会meet_lock指标会这么高?下面我们再通过 TiDB 日志分析一下。

3. TiDB 日志分析

通过关键字"prewrite encounters lock" 过滤预写阶段遇到的锁冲突的tableID:

grep “prewrite encounters lock” tidb.log |awk -F “tableID” ‘{print $2}’ | awk -F “,” ‘{print $1}’ | sort | uniq -c > pe.log

通过关键字"Write conflict 过滤写冲突的tableID:

grep “Write conflict” tidb.log |awk -F “tableID” ‘{print $2}’ | awk -F “,” ‘{print $1}’ | sort | uniq -c > wc.log

cat wc.log
1 =24289
86 =24900
5 =25849
3 =27930
86表示冲突次数,24900表示tableID。

但量过滤出来的冲突次数也不多,说明锁冲突的原因不在这里,下面查找TiKV日志。

4 TiKV 日志分析

[2021/06/23 14:59:24.085 +08:00] [WARN] [endpoint.rs:537] [error-response] [err=“Key is locked (will clean up) primary_lock: 7480000000000073E15F728000000000201B3C lock_version: 425834987480679159 key: 7480000000000073E15F728000000000201B3C lock_ttl: 20631 txn_size: 10 lock_for_update_ts: 425834987480679159”]

[2021/06/23 14:59:24.085 +08:00] [WARN] [endpoint.rs:537] [error-response] [err=“Key is locked (will clean up) primary_lock: 7480000000000073E15F728000000000186E7D lock_version: 425834987454465021 key: 7480000000000073E15F72800000000104676B lock_ttl: 21177 txn_size: 28 lock_for_update_ts: 425834987454465021”]

[2021/06/23 14:59:24.088 +08:00] [WARN] [endpoint.rs:537] [error-response] [err=“Key is locked (will clean up) primary_lock: 7480000000000073E15F728000000000186E7D lock_version: 425834987454465021 key: 7480000000000073E15F72800000000104676F lock_ttl: 21177 txn_size: 28 lock_for_update_ts: 425834987454465021”]

[2021/06/23 14:59:24.089 +08:00] [WARN] [endpoint.rs:537] [error-response] [err=“Key is locked (will clean up) primary_lock: 7480000000000037A95F698000000000000001013036363634366239FF6661636532623036FF3635353738613837FF3139333964313330FF0000000000000000F7 lock_version: 425834986536960179 key: 7480000000000037A95F698000000000000004013735333464366666FF3166313439373739FF3365366431333531FF3835363861386464FF0000000000000000F7038000000065F421CC lock_ttl: 5380 txn_size: 2 lock_type: Del lock_for_update_ts: 425834986536960179”]

TiKV日志当中有很多Key is locked (will clean up),这段报错信息表示出现了读写冲突,当读数据时发现 key 有锁阻碍读,这个锁包括未提交的乐观锁和未提交的 prewrite 后的悲观锁。

  • primary_lock:锁对应事务的 primary lock。
  • lock_version:锁对应事务的 start_ts。
  • key:表示被锁的 key。
  • lock_ttl: 锁的 TTL。
  • txn_size:锁所在事务在其 Region 的 key 数量,指导清锁方式。

下面过滤出出现次数最多的 primary_lock
cat tikv.log |grep error-response | awk -F “primary_lock:” ‘{print $2}’ | awk -F " " ‘{print $1}’ | sort | uniq -c | sort -n

通过region key 命令找到 region

tiup ctl pd -u http://{pdip:port} -i

region key 7480000000000073E15F728000000000415EDF

然后通过region查找表结果显示not found

curl http://{tidbip}:10080/regions/1412629

region not found for regionID 1412629

查看一下 region 元数据信息,显示这是个空region

SELECT * FROM INFORMATION_SCHEMA.TIKV_REGION_STATUS WHERE region_id=1412629

通过监控面板发现集群有1700+empty-region-count,下面合并空 region 看看能不能解决锁冲突异常监控数据。

tiup ctl pd -u http://{pdip:port} -i

config set max-merge-region-keys 10

config set max-merge-region-size 100

config set merge-schedule-limit 16

config set region-schedule-limit 4

config set key-type raw

合并完记得修改回来

config set max-merge-region-keys 200000

config set max-merge-region-size 20

config set merge-schedule-limit 16

config set region-schedule-limit 4

config set key-type table

结果:
大概2小时左右空region合并完,最后还有50个左右无法合并。
锁冲突信息明显降低,说明有效果。 具体为什么空region会导致锁冲突还不知道。

如果还有很多锁冲突,可以通过tidb和tikv日志继续排查。

或者通过慢查询日志过滤:Exec_retry_count 表示重试次数
grep Exec_retry_count /data/tidb_data/log/tidb_slow_query.log

6赞

:+1::+1::+1:

1赞

hello,请问您合并完空region后还出现锁冲突了吗,我们这个环境,我看alter里有很多TIKV_coprocessor_request_error和tidb_tikvclient_backoff_seconds_count报错,感觉和您的情况很像

1赞

锁冲突大多数都是由于多个线程并发执行时,有重复数据导致的(主键重复)。

可以把审计日志打开后,通过下面关键字过滤汇总一下。看看哪个表的冲突比较多,针对性的优化。
grep “Write conflict” tidb.log

2赞

好的,我明天看一下,多谢您的回复,有疑问的话,还会再请教您~

1赞

您好 我也遇到了这个情况 请问有办法指定空region 和并吗 您的这个方法是全部自动合并 不知道对线上会不会有压力呢

1赞

是的,合并空region,这边每隔一段时间就会操作一次。 线上基本无感。

1赞

config set key-type raw 您好 这个跨表合并region 有没有必要开启 开启的话是不是 一个region里可能存有多个表数据

1赞

空region比较多的时候开启处理一下就行,没必要一直开着,一直开启一些小表的数据可能都跑到一个region上面去了。

1赞

您好 如果不开枪跨表合并 不属于任何表的空region是不是就不会合并了

1赞

是的。

1赞