tidb: Killing connections needs cooperation from the to-be-killed connection
Bug Report
1. Minimal reproduce step (Required)
- Run TiDB playground.
- Connect two sessions with
mysql --host 127.0.0.1 --port 4000 -u root -p
- From connection A: run
SHOW PROCESSLIST
and get the connection ID of the other connection (mysql
reports its own connection id when starting up) - Now from connection A issue:
KILL TIDB CONNECTION <id>
where ID is the connection ID of the other connection. - Now run
SHOW PROCESSLIST
again.
Note that this is with a single tidb
node.
2. What did you expect to see? (Required)
The killed connection gone from the processlist.
3. What did you see instead (Required)
The other connection still being in the processlist until it tries to run a query.
Once a query like do 1
is attempted on connection B the connection is gone from the processlist and connection B shows ERROR 2013 (HY000): Lost connection to MySQL server during query
4. What is your TiDB version? (Required)
mysql> select tidb_version()\G
*************************** 1. row ***************************
tidb_version(): Release Version: v5.0.0
Edition: Community
Git Commit Hash: bdac0885cd11bdf571aad9353bfc24e13554b91c
Git Branch: heads/refs/tags/v5.0.0
UTC Build Time: 2021-04-06 16:36:29
GoVersion: go1.13
Race Enabled: false
TiKV Min Version: v3.0.0-60965b006877ca7234adaced7890d7b029ed1306
Check Table Before Drop: false
1 row in set (0.00 sec)
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 23 (20 by maintainers)
Commits related to this issue
- server: fix show problem for kill tidb connection (#24031) (#29212) — committed to pingcap/tidb by yiwen92 3 years ago
- Revert "server: fix show problem for kill tidb connection (#24031) (#29212)" This reverts commit 52c68908d410570bc5b65cca4f9e4380769b4be5. — committed to bb7133/tidb by bb7133 2 years ago
- server: a better way to handle killed connection (#32809) close pingcap/tidb#24031, ref pingcap/tidb#29212 — committed to pingcap/tidb by bb7133 2 years ago
- server: a better way to handle killed connection (#32809) (#37834) close pingcap/tidb#24031, ref pingcap/tidb#29212 — committed to pingcap/tidb by ti-srebot 2 years ago
- server: a better way to handle killed connection (#32809) (#38888) close pingcap/tidb#24031, ref pingcap/tidb#29212 — committed to pingcap/tidb by ti-chi-bot 2 years ago
- server: a better way to handle killed connection (#32809) (#38887) close pingcap/tidb#24031, ref pingcap/tidb#29212 — committed to pingcap/tidb by ti-chi-bot 2 years ago
@morgo minor remark: MySQL uses
Killed
instead ofkilled
. Would be good to keep this identical if possible.I took a look at this today. The issue is as described; killing a connection sets
cc.status
toconnStatusWaitShutdown
, which is read on the next interaction in that session, and then the connection is killed.My suggestion to fix it is the following:
SHOW PROCESSLIST
(and infoschema) is modified to show theState
asKilled
.waitTimeout
, the code is instead modified to have a hard coded 2s timeout, but loops for up towaitTimeout
retrying a read:https://github.com/pingcap/tidb/blob/0c7283418ba8f2638a84626c358b14ad673b60e9/server/conn.go#L933-L951 We have a similar problem with the sleep function, which handles interuption by looping:
https://github.com/pingcap/tidb/blob/0c7283418ba8f2638a84626c358b14ad673b60e9/expression/builtin_miscellaneous_vec.go#L336-L355
I’ve forked the KILL DDL issue to https://github.com/pingcap/tidb/issues/24144