Monitoring kv Errors

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

Original topic: 监控kv Errors

| username: 点点-求助来了

[TiDB Usage Environment] Production Environment
[TiDB Version] 5.0.1
[Reproduction Path] Operations performed that led to the issue
[Encountered Issue: Issue Phenomenon and Impact]
[Resource Configuration]
[Attachment: Screenshot/Log/Monitoring]

| username: xfworld | Original post link

Is the lock conflict very serious?

| username: 点点-求助来了 | Original post link

Don’t know how to handle it.

| username: xfworld | Original post link

Just take a look at the business-related tables, and it’s best to have them adjust the potential business conflicts to avoid such conflicts.

Refer to the lock troubleshooting documentation:

| username: 点点-求助来了 | Original post link

select * from information_schema.deadlocks; prompts that the table does not exist, what should I do?

| username: xfworld | Original post link

Since version v5.1, TiDB supports the Lock View feature…

You can only consider upgrading; the version is too low, and some new features are not supported. :rofl:

| username: 点点-求助来了 | Original post link

Alright! It looks like we need to upgrade, but the main concern is the risk of upgrading online!

| username: Lucien-卢西恩 | Original post link

Refer to @xfworld’s suggestion. If you are worried about the risks of upgrading, you can analyze and locate the issue using the tikvLockFast read-write conflict troubleshooting method. Lock conflicts are mainly avoided through business logic adjustments and optimizations. The new version offers more efficient visualization of cluster processes and lock issue localization. You need to manage the upgrade version and cluster management strategy yourself.