A large number of TiKV coprocessor request errors with the reason being meet_lock

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 大量 TiKV_coprocessor_request_error reason是 meet_lock

| username: 路在何chu

【TiDB Usage Environment】Production Environment / Testing / PoC
【TiDB Version】
4.0.13
Currently, there’s no significant impact, but there are a lot of these warnings:
Warning: TiKV_coprocessor_request_error

cluster: xxxxxxx
reason: meet_lock
instance: xxxxx: 20180

| username: Billmay表妹 | Original post link

[Reproduction Path] What operations were performed to encounter the issue
[Encountered Issue: Issue Phenomenon and Impact]
[Resource Configuration] Go to TiDB Dashboard - Cluster Info - Hosts and take a screenshot of this page
[Attachment: Screenshot/Log/Monitoring]

Additional Information

| username: Billmay表妹 | Original post link

You can take a look at this article.

| username: 路在何chu | Original post link

I’ve reviewed it, and there are no issues in it.

| username: 路在何chu | Original post link

Filter tableID for lock conflicts encountered during the prewrite phase using the keyword “prewrite encounters lock”:

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

Filter tableID for write conflicts using the keyword “Write conflict”:

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

By following these two steps, you can identify a table that indeed has many conflicts. This table is the core table, ranking first in both reads and writes, but there are no other issues. Is splitting the table the only solution?

| username: tidb菜鸟一只 | Original post link

Version 4.0 is too low, I don’t have any good ideas.

| username: 路在何chu | Original post link

Alright, it means we can only upgrade.

| username: Billmay表妹 | Original post link

If there is no impact, try not to change it for now.

| username: 像风一样的男子 | Original post link

The warning can be ignored.

| username: 有猫万事足 | Original post link

There’s no need, right? Although conflicts may affect performance a bit, this is a necessary cost for business correctness.

Maybe the business just needs this distributed lock. It’s just a matter of whether to put it in the database or in Redis/Zookeeper.

It’s just a matter of whether the database outputs the logs or the application side outputs the logs.

Splitting the table doesn’t seem to have much effect.

| username: 路在何chu | Original post link

Well, just increase the monitoring threshold.

| username: 有猫万事足 | Original post link

Urge the R&D team to learn the technology.
Just search on Bilibili for “Redis + distributed lock,” and you’ll find a ton of interview guides explaining it. :rofl:

| username: 路在何chu | Original post link

This is a bit difficult.

| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.