Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: tidb 日志有很多error，修改ttl状态，会和莫名的ip建立连接，这个ip不是tidb集群的ip
|
username: TiDBer_oDmMGRXY
The images you provided are not visible. Please provide the text content you need translated.
The logs of these three images are continuously being printed.
It’s hard to identify the issue this way. If possible, could you share the complete configuration process and the context of the logs?
Is the configuration process referring to the configuration file during installation?
The main reason for the high CPU usage of the TiDB server is that the execution of SQL statements consumes a lot of CPU resources. You can use the EXPLAIN ANALYZE command to analyze the execution plan of the SQL statement and optimize it accordingly. Additionally, you can check the CPU usage of each thread in the TiDB server to identify the threads that consume the most CPU resources.
/tidb-deploy/ is the installation directory of TiDB. The configuration file does not have this IP. I also found that this IP changes. The IP I sent the first time is different from the IP I sent the second time.
I haven’t changed my TiDB configuration file since the installation; it’s just like this.
This is a bug. See the link above.
The difference is only in line 50 of ttl/ttlworker/job.go, where some parameters are forcibly converted to strings.
|
username: 
|
username: 
|
username: old||return updateJobCurrentStatusTemplate, []interface{}{newStatus, tableID, oldStatus, jobID}|
new||return updateJobCurrentStatusTemplate, []interface{}{string(newStatus), tableID, string(oldStatus), jobID}|
I see that in the LTS version, it is still written as above up to 6.5.3, and it only changes to the below version in 7.1.0. I guess you need to upgrade to 7.1.0 to resolve this error.
Another issue is that TiDB seems to have failed to write data to the remote connection on port 3306. As long as the person using this library doesn’t complain, I think you can ignore it. 
Upgrading is not a trivial matter. Be cautious when upgrading production systems. Alternatively, you can simply avoid using the TTL feature. I guess the R&D team is trying out new things. You can also manage deletions through the application instead of using the database.
The development colleagues mainly want to use the TTL feature. Previously, using MySQL partitions required manual deletion on a regular basis, and creating partitions was very troublesome. That’s why they chose to use TiDB. 
Then upgrade. If there are risks, I think they will understand. We’ll face the difficulties together.
Sure, I’ll research it, thank you. Currently, it’s just a log error, and I haven’t seen any impact on the business yet.