作者： 连连看db

一、背景

tidb版本5.3，一天prometheus的tikv突然告警，报警内容包含关键字meet lock，10分钟大于10000次meet lock。

TiDB主键锁（primary key lock）问题诊断_delete



二、排查过程

    部门有要求，一旦报警，需要确定报警具体原因，所以开始以下排查

1、首先排查TiDB集群访问延迟是否在正常范围

TiDB主键锁（primary key lock）问题诊断_meta_02

平均访问延迟在100ms以下，没有对业务造成影响，但需要关注，排除隐患。

2、查看tikv日志

TiDB主键锁（primary key lock）问题诊断_tikv_03

根据官方文档描述：

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

找到primary_lock频率比较高的key

cat tikv.log |grep error-response | awk -F "primary_lock:" '{print $2}' | awk -F " " '{print $1}' | sort | uniq -c | sort -n24 7480000000000001CA5F6980000000000000010380000000031E2BCA038000000000142F42038005E5362CD7765024 7480000000000001CA5F6980000000000000010380000000031E2BCA038000000000142F42038005E53639926B4824 7480000000000001CA5F6980000000000000010380000000031E2BCA038000000000142F42038005E5363B41404024 7480000000000001CA5F6980000000000000010380000000076F740903800000000014AFE0038005E53639926B4824 7480000000000001CA5F69800000000000000103800000000AC2A32B038000000000134436038005E52CA7AF566825 7480000000000001CA5F6980000000000000010380000000031E2BCA038000000000142F42038005E53639F48C6025 7480000000000001CA5F6980000000000000010380000000031E2BCA038000000000142F42038005E5363A5048C025 7480000000000001CA5F6980000000000000010380000000076F740903800000000014AFE0038005E5363B41404025 7480000000000001CE5F698000000000000001038000000005F3DFF103800000000014B9D1038005E5366AF4C89826 7480000000000001CA5F6980000000000000010380000000076F740903800000000014AFE0038005E5363B93501028 7480000000000001CA5F6980000000000000010380000000031E2BCA038000000000142F42038005E5363B93501028 7480000000000001CA5F6980000000000000010380000000076F740903800000000014AFE0038005E5363A5048C035 7480000000000001CA5F698000000000000001038000000005F3DFF103800000000014B9D1038005E5363C55A9F8
  • 1.

3、prometheus监控

TiDB主键锁（primary key lock）问题诊断_meta_04

tidb官方文档关于锁冲突的描述

TiDB主键锁（primary key lock）问题诊断_delete_05

TiDB主键锁（primary key lock）问题诊断_tikv_06

4、定位造成读写锁的相关表和SQL语句，使用一个小工具叫mok。

下载地址：https://github.com/disksing/mok

下载好工具后，根据上面tikv日志中的被锁的key，定位是哪张表的主键。

TiDB主键锁（primary key lock）问题诊断_tikv_07

具体看红框内容：

TiDB主键锁（primary key lock）问题诊断_meta_08

根据上图的表ID可以定位到异常表名:ch_im

TiDB主键锁（primary key lock）问题诊断_https_09

TiDB主键锁（primary key lock）问题诊断_meta_10

5、在“sql语句分析“中找到该时间段的相关SQL

TiDB主键锁（primary key lock）问题诊断_tikv_11

TiDB主键锁（primary key lock）问题诊断_meta_12



三、总结

    本次meta_lock的报警问题是由于delete语句中in的数量较多，与生产业务的insert ignore into 发生锁冲突。虽然没有业务上的影响，但一些小的异常报警，也需要我们提前优化，避免出现更大的问题。

解决方案如下：

1、少量读写冲突（tikvLockFast）或写写冲突（txnLock），集群访问延迟没有明显增加，不需要处理；

     2、根据业务请求分析，优化读、写的慢SQL：调整插入批量size 100 -> 10，调整delete 语句in的数量，减少读写冲突概率；

     3、修改事务锁模式，乐观锁→悲观锁；

     4、 关闭异步提交（async commit），tidb 5.0默认开启异步提交。

  具体可参考：         https://docs.pingcap.com/zh/tidb/stable/system-variables#tidb_enable_async_commit-%E4%BB%8E-v50-%E7%89%88%E6%9C%AC%E5%BC%80%E5%A7%8B%E5%BC%95%E5%85%A5



四、优化前后效果

可以看到在使用以上方法后，meta_lock 的问题大幅减少，趋于平稳。

TiDB主键锁（primary key lock）问题诊断_delete_13