[Bug]: `kill query $connection_id` returns ok but the query is not killed
DanielZhangQD opened this issue · comments
Is there an existing issue for the same bug?
- I have checked the existing issues.
Branch Name
1.2-dev
Commit ID
v1.2.0-6391c3626-2024-06-09
Other Environment Information
- Hardware parameters:
- OS type:
- Others:Actual Behavior
- Create a new instance in cloud dev
- Load the tpch sample data
- login session 1 with MySQL cli, get the connection ID 1
- use mo_sample_data_tpch_sf10;
- select * from lineitem
- login session 2 with MySQL cli
- kill query $connection_id_1, the kill SQL succeeded, but the query was not killed
mysql> kill query 73366871;
Query OK, 0 rows affected (0.03 sec)
mysql> select statement,status,duration from system.statement_info where statement_id = '01900b56-3885-77b1-a991-93a5ca137692' and request_at >= '2024-06-12 07:20:00';
+------------------------+---------+--------------+
| statement | status | duration |
+------------------------+---------+--------------+
| select * from lineitem | Success | 346496750298 |
+------------------------+---------+--------------+
1 row in set (0.34 sec)
Expected Behavior
Query is killed or error returned if it's not killed
Steps to Reproduce
See detail in Actual BehaviorAdditional information
Cloud dev env
来不及
DELAY 1.2.2版本
未投入
无投入
这个要求做不到：" error returned if it's not killed"。
计算引擎在被kill时没有给定一个立即退出或返回错误的行为。
1，issue中的例子执行时间太短了。0.34秒结束，拼手速。如果mo在执行完sql,才受到kill，实际没作用。
2，受到kill与执行sql是一种异步行为。
3，如果是34s,或者更长的时间。kill不掉，要case by case看了。大部分的sql都能kill掉。
346496750298 是大概 346s.
mysql> select count() from lineitem;
+----------+
| count() |
+----------+
| 59986052 |
+----------+
mysql链接并kill的情况
15566 11:51:24.767863812 127.0.0.1 34628 127.0.0.1 MySQL 93 [TCP ACKed unseen segment] Request Query { select * from lineitem } 6001
124085 11:51:34.627951568 127.0.0.1 49770 127.0.0.1 MySQL 85 [TCP ACKed unseen segment] Request Query { kill query 101 } 6001
124137 11:51:34.629622177 127.0.0.1 6001 127.0.0.1 MySQL 3925 Response Response 34628
执行结束时间点
jdbc链表并执行kill的情况1： jdbc client 不输出查询结果
14964 12:18:17.934669025 127.0.0.1 52326 127.0.0.1 MySQL 102 Request Query { select * from tpch_10g.lineitem } 6001
571510 12:18:56.013165535 127.0.0.1 49770 127.0.0.1 MySQL 85 Request Query { kill query 155 } 6001
571729 12:18:56.019745663 127.0.0.1 52326 127.0.0.1 MySQL 71 Request Quit 6001
用分支 github.com/daviszhen/matrixone/pull/new/0625-debug-16824
结合本地用proxy 启动双cn. https://github.com/daviszhen/morunner/blob/main/README.md#pr-checklist
浮现出来。proxy在kill 时，行为有问题。
执行kill语句时
kill query 10201;
proxy 会通过extra info将新session的id 改为10201。这导致实际10201的链接是杀不掉的。
==testkill new session id 019054a1-6489-7f2f-b548-aa1fe55e6c9c new connid 10201 hakeeper id 10012 idBefore 10012 idAfter 10201
之前一直以为pipeline的ctx 传第 有中断，导致下面的RUN的ctx 没有被cancel
fixed
commit_id: a0f75f6
测试通过。
这里要确认 statement_info 里面的 状态，确认 SQL 是真的被 kill 了还是执行成功了。
commit_id: a0f75f6
测试通过。这里要确认 statement_info 里面的 状态，确认 SQL 是真的被 kill 了还是执行成功了。
以上kill成功了，但是statement_info表中关于这条sql的信息展示为success.已经麻烦泽雄哥帮忙看了
单机环境测试不通过。
分布式环境kill后没起作用：
commit：ea4a155
测试步骤：
- 首先查看connection_id();
- 执行sql： select count(distinct(col10)) from big_data_test.table_basic_for_load_100M;（这条sql正常执行需要44s）；
- 执行sql期间在另一个session里kill query + connection，观察步骤2中的sql是否会中断执行
分布式环境测试不通过
总结：
- 单机环境，kill成功，但是statement_info表中的状态是success；
- 分布式环境，kill不成功。
commit_id: a0f75f6
测试通过。这里要确认 statement_info 里面的 状态，确认 SQL 是真的被 kill 了还是执行成功了。
以上kill成功了，但是statement_info表中关于这条sql的信息展示为success.已经麻烦泽雄哥帮忙看了
单机环境测试不通过。
补充一下：statement_info的 status主要依赖 frontend提供的执行结果，frontend的执行链路挺复杂的。
一行错误日志 "query trace status" ，可以直观区分出哪边出问题：1）原query的执行status结果不对；2）statement_info记录的不对。
后续验证时，可关注该日志。 @Ariznawlll
回归不通过，非重要问题，不在1.2.2解决了，DELAY到 1.3.0