Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: 日志级别为error时不统计慢查询
[TiDB Usage Environment] Production
[TiDB Version] 5.7.25-TiDB-v5.1.0
[Encountered Issue]
The enable-slow-log is set to true, but there is no data in the slow queries on the Dashboard, and there are no records when querying INFORMATION_SCHEMA.CLUSTER_SLOW_QUERY.
I checked historical posts, and there is a description that it is caused by the log level being set to error. Is this the reason? Is there a plan to fix it?
I verified that adjusting log.level to info does indeed record slow queries. However, setting log.level to info generates too many logs.
- Manual testing did not reproduce the issue of slow logs not being recorded at the error level;
- The issue mentioned in the referenced post is likely because the person looked at the corresponding PR for that part of the code, but that logic would not cause this issue. The reason why slow_log is not recorded should be unrelated to the log.level setting. I have replied in the referenced post.
mysql> select sleep(3);
+----------+
| sleep(3) |
+----------+
| 0 |
+----------+
1 row in set (3.00 sec)
mysql> select sleep(3);
+----------+
| sleep(3) |
+----------+
| 0 |
+----------+
1 row in set (3.00 sec)
mysql> select sleep(3);
+----------+
| sleep(3) |
+----------+
| 0 |
+----------+
1 row in set (3.00 sec)
mysql> select * from information_schema.cluster_config where `key` like '%log.level%' and TYPE like '%tidb%';
+------+---------------------+-----------+-------+
| TYPE | INSTANCE | KEY | VALUE |
+------+---------------------+-----------+-------+
| tidb | 172.16.120.122:6000 | log.level | error |
+------+---------------------+-----------+-------+
1 row in set (0.01 sec)
mysql>
mysql> select Query from information_schema.cluster_slow_query where Query like '%sleep%';;
+------------------+
| Query |
+------------------+
| select sleep(3); |
| select sleep(3); |
| select sleep(3); |
+------------------+
3 rows in set (0.00 sec)
mysql> select version();
+--------------------+
| version() |
+--------------------+
| 5.7.25-TiDB-v6.1.0 |
+--------------------+
1 row in set (0.00 sec)
In summary, there is no such issue at the functional level.
I feel that it is most likely a version issue. There were no problems with the previous 4.0.x version, but we encountered this problem with the 5.1 version in a recent project.
What operations did TiDB perform before it stopped recording slow logs?
Did an OOM (Out of Memory) occur? It could be a version issue, but it shouldn’t be a functional problem.
Is there any information that can help pinpoint the root cause? Based on the current information, it seems more like the slow log recording function was restored after a restart.
Just retried it again, the test sequence is as follows, using the -R tidb method during reload:
log.level set to info, recording slow queries
log.level set to warn, recording slow queries
log.level set to error, not recording queries
log.level set to warn, recording slow queries
It is indeed a bug and has been fixed. The affected versions include 5.1.x, 5.2.x, and 5.3.x.
Alright, I was just being lazy at the time and didn’t test it, sorry.
You are right!
I discovered this PR while getting the source code from git, it was quite a coincidence.
Wrote it wrong, wrote it wrong, haha
This topic will be automatically closed 60 days after the last reply. No new replies are allowed.
|
username: Kongdom
|
username: