Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: 假设mysql客户端进程被杀
【TiDB Usage Environment】Production Environment
【TiDB Version】6.5.3
【Reproduction Path】Suppose you find that the client is performing an operation that takes more than 1 hour to complete. You don’t want to wait, so you directly kill the process on the client side. What will the TiDB server do after it stops receiving data packets from the client?
If a complex query is being executed, will the query automatically exit?
If a large transaction is being executed, will the transaction rollback? Will the locks be automatically released?
In versions prior to 7.5, if the client process is killed directly, the database will continue to complete the statement. If a large transaction is being executed, it will succeed if it is auto-commit; if it is not auto-commit, the transaction will roll back and the lock will be automatically released.
In version 7.5, if the client process is killed, the database will terminate immediately, the statement will be killed immediately, the transaction will roll back, and the lock will be released.
I always thought that after killing, the data execution would terminate and roll back. It turns out that before version 7.5, it wouldn’t roll back.
There is no problem using the kill command in the database server, but directly terminating the program on the client side doesn’t work. This requirement was mentioned before, but it was finally implemented in version 7.5.
Oh, so killing is normal, and if you just close the client, it won’t take effect. This is actually expected.
Got it. Previously, I understood that after the client stops, the system will continue to execute until it detects that the session is disconnected, at which point it will automatically roll back and release the lock, but it is quite slow.
If you use PL/SQL Developer with Oracle, clicking “Interrupt” will cause a rollback, but if you directly kill PL/SQL Developer, it will continue to execute.
PL/SQL Developer does not automatically commit transactions by default, meaning that if you execute a transaction, it will lock the data.
Master, may I ask how the TiDB server senses that the client has disconnected? Is this related to TCP long connections?
Mainly relies on heartbeat messages or the KeepAlive mechanism of the TCP protocol.
The client actually sent the command to the server for execution, so if the client is killed, it will not roll back previously.
Isn’t that an issue with your settings? Regardless of whether you submit it or not, the SQL statement you executed needs to be completed.
This bug had a significant impact, and the fix is very well done.
Is there a heartbeat between the client and the server?
The KeepAlive mechanism of the TCP protocol
Got it, thanks for the explanation.
Got it. Thanks for the explanation, expert.
The client in version 6.5 restarted, but TiDB continued to execute and could only be killed manually. Thumbs up for the new features in version 7.5.
|
username: vincentLi
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: