Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: kill 命令无效
|
username: 等一分钟
【TiDB Usage Environment】Production Environment
【TiDB Version】6.5.1
Killing the slow SQL ID online did not take effect.
The image you provided is not visible. Please provide the text you need translated.
It might be that the SQL execution took too long, and the rollback needs some time.
[2023/04/24 18:09:52.905 +08:00] [INFO] [server.go:769] [kill] [connID=5853656969768947107] [query=false]
[2023/04/24 18:09:54.345 +08:00] [WARN] [server.go:612] [“Server.onConn handshake”] [conn=5853656969768958439] [error=“write tcp 10.0.254.170:4000->100.116.243.1:49886: write: connection reset by peer”] [“remote addr”=100.116.243.1:49886]
[2023/04/24 18:09:54.686 +08:00] [WARN] [server.go:612] [“Server.onConn handshake”] [conn=5853656969768958441] [error=“write tcp 10.0.254.170:4000->100.116.152.1:32183: write: connection reset by peer”] [“remote addr”=100.116.152.1:32183]
Have you enabled the global kill feature parameter?
Or explicitly log in to the TiDB server where the SQL is located and then execute the kill operation.
There is this bug in version 5.1, where executing the kill command results in the SQL not being terminated. However, your version is 6.1, which should have already fixed this issue. Are you sure you logged into the corresponding node?
I’ve encountered this many times. Even if it’s not a slow SQL, it can’t be killed, and I end up restarting the TiDB server. 
The kill command was executed in the tidb_server.
What is the function of global kill?
It means that a TiDB node can kill all TiDB processes within the cluster.
It should be a bug. I’ve encountered this issue in many versions.
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
…enable-global-kill Introduced Starting from Version v6.1.0
|
username: