Assume that the client issues a long running query that mutates the database.
During the query the TCP connection between the client and the server is closed or interrupted unexpectedly.
I'd be curious what happens on the server side. Will MySQL rollback the query once it discovers that the client is gone, or it just leaves it as is?
I understand that there may be different behaviours depending on
query type (transaction or regular query etc)
MySQL version
disconnect type (TCP FIN/RST or just the cable is simply unplugged)
Related
I'm looking into aborted connection -
2022-11-21T20:10:43.215738Z 640870 [Note] Aborted connection 640870 to db: '' user: '' host: '10.0.0.**' (Got timeout reading communication packets)
My understanding is that I need to figure out whether it is an interactive or not connection, and increase wait_timeout (or interactive_timeout) accordingly. If it has no effect, then I'll need to adjust net_read_timeout or net_write_timeout and see.
I'd like to ask:
Is there a meta table that I can query for the connection type
(interactive or not)?
There are how-to's on the internet on adjusting wait_timeout (or
interactive_timeout) and all of them have rebooting the database as
the last step. Is that really required? Given that immediate effect
is not required, the sessions are supposed to come and go, and new
sessions will pick up the new value (after the system value is set),
I suppose if there is a way to track how many connections are left
with the old values, then it will be ok?
Finally, can someone suggest any blog (strategy) on handling aborted
connection or adjusting the timeout values?
Thank you!
RDS MySQL version 5.7
There is only one client that sets the interactive flag by default: the mysql command-line client. All other client tools and connectors do not set this flag by default. You can choose to set the interactive flag, because it's a flag in the MySQL client API mysql_real_connect(). So you would know if you did it. In some connectors, you aren't calling the MySQL client API directly, and it isn't even an option to set this flag.
So for practical purposes, you can ignore the difference between wait_timeout and interactive_timeout, unless you're trying to tune the timeout of the mysql client in a shell window.
You should never need to restart the MySQL Server. The timeout means the client closed the session after there has been no activity for wait_timeout seconds. The default value is 28800, which is 8 hours.
The proper way of handling this in application code is to catch exceptions, reconnect if necessary, and then retry whatever query was interrupted.
Some connectors have an auto-reconnect option. Auto-reconnect does not automatically retry the query.
In many applications, you are borrowing a connection from a connection pool, and the connection pool manager is supposed to test the connection before returning it to the caller. For example running SELECT 1; is a common test. The action of testing the connection causes a reconnect if the connection was not used for 8 hours.
If you don't use a connection pool (for example if your client program is PHP, which doesn't support connection pools as far as I know), then your client opens a new connection on request, so naturally it can't be idle for 8 hours if it's a new connection. Then the connection is closed as the request finishes, and presumably this request lasts less than 8 hours.
So this comes up only if your client opens a long-lived MySQL connection that is inactive for periods of 8 hours or more. In such cases, it's your responsibility to test the connection and reopen it if necessary before running a query.
I have two FireDAC connections on my application, one is intended to be used on a MySQL Server that is on LAN and store private data of the my shop (like sales, products, etc), and the another one is connected to a remote (internet) MySQL Server, and it randomly give me a exception
First chance exception at $745AA882. Exception class
EMySQLNativeException with message '[FireDAC][Phys][MySQL] Lost
connection to MySQL server during query'.
Is this a issue on FireDAC, my code or the remote MySQL Server?
Using NAVICAT software I have no problem.
This error usually occurs because the Internet Connectivity is not stable and connection closed during exchanging data
Sometimes you can solve this issue with increasing the connection Time-Out (and ReadTimeOut )
Sometimes this error occurs because you are trying to send or receive large amount of data like Blob fields and you should increase the max_allowed_packet variable of MySQL Server to solve the problem
The next suggestion for solving this problem is avoiding dns lookup by adding skip-name-resolve to the settings of your MySQL Server
The Main reasons of this problem is connection stability and MySQL Server Settings
If you have access to MySQL server and can change the settings, this link may be useful :
http://www.monitis.com/blog/101-tips-to-mysql-tuning-and-optimization/
You can find many articles about increasing performance of MySQL Server
we have mysql-server(5.5.47)that hosted on physical server. It listen external internet interface(with restrict user access), mysql server intensively used from different places(we use different libraries to communicate with mysql). But sometimes whole mysql server(or network) stuck and stop accept connection, and a clients failed with etimedout(connect)/timeout(recv), even direct connection from server to mysql with mysql cli not working(stuck without any response — seems to be try to establish connections).
First thought was that it is related to tcp backlog, so mysql backlog was increased — but this not help at all.
Issue not repeatable, so last time when this issue happened we sniff traffic, and what we get:
http://grab.by/STwq — screenshot
*.*.27.65 — it is client
*.*.20.80 — it is mysql server
From session we can assume that tcp connection established, but server retransmit SYN/ACK to client(from dump we see that server receive ACK, why retransmit ?), but in normal case mysql must generate init packet and send to client, after connection was established.
It is only screen from 1 session, but all other sessions mostly same, SYN -> SYN/ACK -> ACK -> and server retransmit SYN/ACK up to retries_count.
After restart mysql all get normal immediately after restart. So not sure it is related to network or mysql.
Any thoughts would be appropriate.
Thank you!
My application makes queries to MySQL using JDBC. Sometimes, while a query is running, connectivity will be lost to the server. Rather than detecting this and throwing an exception, the code hangs until the TCP connection finally times out (which takes over 10 minutes)
Setting a query timeout doesn't work. If the DB server stays up this will timeout queries, but does nothing if the server goes down before the timeout triggers.
Setting socketTimeout in the MySQL connection string or invoking .withNetworkTimeout on the Connection object sort of works. This does force the connection to timeout if no response is received after the specified timeout, however it will also kill queries that run longer than the timeout even if the DB server is up. I want to die fast if the DB server goes down but still be able to run long queries.
If I could get at the sockets Keepalive settings so I could set the interval/number of probes lower and that would solve the problem, but I can't see anyway to do that with the MySQL JDBC driver.
How can I cause queries to fail quickly when the DB server goes down, while still being able to run long queries?
This question is theoretical. I've no real use case; I'm just trying to understand the MySQL behaviour.
Suppose I send a query (or a transaction) to the server (using transactional tables of course), and the query or transaction executes fine, but the connection is lost before the client (f.e., mysql or an App connecting to a remote server throught a C interface or any other framework like QtSQL) receives the answer of the server. So, the server knows the transaction finished properly, but the client doesn't because the answer didn't arrive.
What does it happen in this case? Does the server roll back the transaction even knowing that it finished succesfully? Any option to control the behaviour in these scenaries?