Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: 告警大量的tidb_tikvclient_backoff_seconds_count
[TiDB Usage Environment] Production Environment
[TiDB Version] 4.0.13
[Encountered Problem: Phenomenon and Impact]
A large number of tidb_tikvclient_backoff_seconds_count alerts, and a lot of Write conflict in the tidb logs. Does anyone have a solution? Additionally, how can I find the table name corresponding to tableid 299 in the logs?
[Attachments: Screenshots/Logs/Monitoring]
Got it! Please provide the Chinese text you need translated.
This is caused by slow SQL.
How to find the table name based on the table ID?
TiDB Lock Conflict Troubleshooting
It has nothing to do with slow SQL.
select `TIDB_TABLE_ID`, TABLE_SCHEMA, TABLE_NAME from INFORMATION_SCHEMA.`TABLES` where TIDB_TABLE_ID=XXXXX;
The number of retries when an error occurs while accessing TiKV. If this error is not particularly frequent, it can be ignored, or the threshold can be increased.
There is a table id in INFORMATION_SCHEMA.TABLES.
It always reports around 200 each time.
Is it possible that batch operations are causing frequent region changes? We are ignoring warnings and only sending error alerts. Generally speaking, this warning does not affect the business.
For a while, I also frequently encountered this warning, but it disappeared after upgrading the KV configuration.
Looking at the documentation, this is normal. It’s just that the concurrency is too high.
Try changing the value of the tikv-client.commit-timeout parameter, for example, adjusting it from the default value to a larger value, such as 120s. This can increase the transaction commit timeout.
In general, in such cases, you will definitely see this table on the heatmap. The read and write volumes should be quite large, so consider splitting the business.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.