DataGrip客户端连接tidb后跑一个sql，取消后实际sql仍在运行且无法kill

zhihui · 2024 年6 月 27 日 03:04

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】DataGrip客户端连接tidb后跑一个sql，取消后实际sql仍在运行且无法kill
影响：发送慢sql提醒

从12点发现sql开始介入，kill 5675698813792416261; 无效，据报警信息显示一直跑到下午两点半。
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】

小龙虾爱大龙虾 · 2024 年6 月 27 日 03:58

7.3 版本后支持 ctrl+c 停止执行语句,你看下你的参数设置对不

github.com/pingcap/tidb

Support CTRL-C or kill <connId> to kill a connection/query by implementing global connection IDs

opened 07:05PM - 27 Dec 18 UTC

closed 09:34PM - 15 Aug 22 UTC

morgo

type/enhancement type/feature-request feature/accepted

* [x] 64bits implementation #17649 * [x] 32bits design doc #20749 * [ ] 32bits… connection ID part #25385 ## Description **Is your feature request related to a problem? Please describe:** Currently connection ids are local to TiDB servers, which means that a `KILL x` must be directed to the correct server, and can not safely be load balanced across the cluster. This is annoying because it creates affinity to servers in a distributed architecture. It also doesn't retrofit to MySQL so well, since the `KILL x` syntax can't be supported (using `KILL TIDB x` to prevent incorrect usage). **Describe the feature you'd like:** I found this note while reading the source code, and it makes a lot of sense to me. I decided to create this FR for discussion and tracking since I couldn't find an existing one open. ``` parser/ast/misc.go: // TiDBExtension is used to indicate whether the user knows he is sending kill statement to the right tidb-server. // When the SQL grammar is "KILL TIDB [CONNECTION | QUERY] connectionID", TiDBExtension will be set. // It's a special grammar extension in TiDB. This extension exists because, when the connection is: // client -> LVS proxy -> TiDB, and type Ctrl+C in client, the following action will be executed: // new a connection; kill xxx; // kill command may send to the wrong TiDB, because the exists of LVS proxy, and kill the wrong session. // So, "KILL TIDB" grammar is introduced, and it REQUIRES DIRECT client -> TiDB TOPOLOGY. // TODO: The standard KILL grammar will be supported once we have global connectionID. ``` Since I believe the connectionID must be 32-bits for protocol compatibility, I assume that the implementation will use the first 8-16 bits for the host, and the remaining 16-24 bits for the local connectionID? It would be nice to externalize the host portion as a pseudo `server_id`, since some functions such as [UUID_SHORT](https://github.com/pingcap/tidb/issues/4620) depend on it being small. The pseudo `server_id`'s can be recycled as TiDB servers are deployed/disappear, with pd ensuring they are unique. This address size of the pseudo server_id would limit the max number of tidb servers deployed simultaneously. **Describe alternatives you've considered:** Using 8 bits for the host seems short, but actually using only 16 bits for the local connection Id is also dangerously low, if you want to make sure new connection Ids allocated do not chase the tail of old connectionIds. I will let someone smarter figure that out :-) **Teachability, Documentation, Adoption, Migration Strategy:** It makes sense to extend `SHOW PROCESSLIST` to be `SHOW [GLOBAL|SESSION] PROCESSLIST`. I think the default of global makes more sense ## Recommended Skills * Golang * tidb-server and pd-server ## Learning Materials * Chinese: [TiDB 精选技术讲解文章](https://github.com/pingcap/presentations/blob/master/hackathon-2019/reference-document-of-hackathon-2019.md) * English: [Awesome-Database-Learning](https://github.com/pingcap/awesome-database-learning)

https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file#enable-global-kill-从-v610-版本开始引入

kill 不掉可能是正常的，代码还没跑到那里