I changed these timeouts globally with:
SET GLOBAL wait_timeout=30; SET GLOBAL interactive_timeout=30
and noticed that I have another application running which got problems with these "low" timeouts. So I would like to undo this and only apply it to the specific database.
I have the same problem in 5.5.43. I was having the "has gone away" error message for some long queries beyond about 2 minutes. So I tried these 3:
(1) SHOW VARIABLES LIKE 'wait_%';
(2) SHOW global VARIABLES LIKE 'wait_%'; and
(3) SHOW session VARIABLES LIKE 'wait_%'; .
All showed wait_timeout to be 28800. Then I added wait_timeout = 31536000 to /etc/my.cnf. Then my long query was able to complete. And from the 3 ways of showing variables above, only (2) the one with "global" showed a change from 28800 to 31536000. The other 2 were unaffected. Since my long-query was definitely less than 10 minutes long, does this mean that the unit of time used here was milliseconds rather than seconds?
Referring to the MySQL Manual the default values for -
wait_timeout and for interactive_timeout are - 28800 seconds
REMEMBER - seconds (28800 in seconds)
Referring to the MySQL Manual the default values for wait_timeout and for interactive_timeout are - 28800.
On thread startup, the session wait_timeout value is initialized from the global
wait_timeout value or from the global interactive_timeout value, depending on the
type of client (as defined by the CLIENT_INTERACTIVE connect option to
mysql_real_connect()). See also interactive_timeout.
Related
I'm running a Galera Cluster with a HAProxy-LB in front.
However my users reporting that the session variable wait_timeout is set to 60.
I checked that with
SHOW SESSION VARIABLES LIKE "%wait_timeout%"
and for me the result is wait_timeout 610.
In my /etc/mysql/my.cnf (on every cluster node) the value "28800" is set (as default)
I can confirm that this is used by running:
SHOW GLOBAL VARIABLES LIKE "%wait_timeout%"
as the result is wait_timeout 28800
Any ideas why this does not apply to new sessions? The HAProxy is afaik just a stupid forwarder on port 3306..
Edit: Updated all the packages on all cluster nodes. Still the same issue.
I even tried to check it with the mysql socket connection for root and the new session spawns with a wait_timeout value of 60.
In general the SESSION VARIABLES are initialized to the GLOBAL settings at the time of establishing the connection. After that, either set of settings could be changed.
However, wait_timeout is especially tricky. Not only are there SESSION and GLOBAL, but there are also interactive and batch. Also, InnoDB has a similar value.
610 is an unusual value. Some person or some program must have changed it.
Are you hitting an unexpected limit?
A "ping" can be used to keep the connection alive.
You can check for the connection having gone away, and restart it.
More specifics for you case, please.
I found the issue.
In a different configuration (some admin had made a separate config for "fine tuning" under /etc/mysql/conf.d/finetuning.cnf) was a variable named interactive_timeout which was set to 60. It seems that this one set the session variable of wait_timeout to 60 instead of using the wait_timeout (28800) from the global variables.
Commenting out the interactive_timeout solved the problem for me.
When manually running an sql query from an app server, if a user just clicks the X to close the window instead of using F12 or the menu to close the connection to the DB, what kind of negative impact can there be?
.
Is there an automatic timeout for connections?
The timeout of a MySQL connection is defined in the /etc/my.cnf file in the wait_timeout server system variable. It's defaulted to 28800 (seconds) - we usually set it for our clients to a very low value - ranging from 10 seconds to 60 seconds. So, if you leave a connection unclosed, then it'll close, by default, after 28800 seconds (that's very high if you have a large number of clients using the app).
In your case, interactive_timeout doesn't apply, since you are not really using the console.
I set
SET GLOBAL max_allowed_packet=16777216;
and also
[mysqld]
max_allowed_packet = 16M
I checked the max_allowed_packet through below command
SHOW VARIABLES LIKE 'max_allowed_packet';
and the value is = 16777216
But after some days max_allowed_packet automatically reset to 1M.
i am pretty sure that your are hacked. i had the same problem for months. i opened general_log and finally found some codes:
connect root#someipaddress on
Query select 0x4D5A900..........(verylong)
Query select sys_exe('cmd /c c:/windows/nbvqc4.vbs')
.........
set global max_allowed_packet 1024
........
suggestion: change your root password.
MySQL has both GLOBAL variables and SESSION variables, as well as the my.cnf.
GLOBAL variables are initialised on startup from my.cnf, and many variables are taken from the GLOBAL value at connection time and copied into the SESSION. If you change the GLOBAL value, the SESSION keeps it's own value -- but any new sessions will take the new GLOBAL default.
It seems that you did the right thing in terms of setting the GLOBAL variable and updating my.cnf, but in your example you ran "SHOW VARIABLES" which returns the SESSION value. So it is possible you were not checking the correct value in that case. I would recommend for all future checks that you check both the global and session values to help get an idea of what is changing when.
SHOW GLOBAL VARIABLES LIKE 'max_allowed_packet';
SHOW SESSION VARIABLES LIKE 'max_allowed_packet';
For the value to change itself later, the following explanations are possible
(1) You are re-using a session that still has the old value
(2) Another connection has run SET GLOBAL max_allowed_packet, it is possible even that some uncourteous application or script is doing this
(3) The server was restarted, and the my.cnf change is not being applied as expected -- perhaps the file is in the wrong path, or the setting exists more than once in the configuration file. I would check the current Uptime in SHOW GLOBAL STATUS to understand if the server was restarted
I cannot think of any other reasons this would occur. I did check to see if the client negotiates the server-side value when you pass --max_allowed_packet but that does not seem to be the case.
Yes, someone hack the system.I changed the root password and everything working fine.
By default value of max_allowed_packet is 1M in MySQL. I believe size of your "max_allowed_packet" is exceed its upper limit. So, when you check "SHOW VARIABLES LIKE 'max_allowed_packet';" its showing some negative value.
Additionally,
You have two values of max_allowed_packet in MySQL :
one on the client side : [mysql] section, [mysqldump], [client] and more.
one on the server side : [mysqld] section.
Try setting 'Super' privilege of all users to 'N', except 1 admin user. This prevents users from changing max_allowed_packet.
We just ran into this issue and the root cause is we were hacked. Some 3rd party was running a script that was changing the value down.
Tip for those trying to figure out if a hack is a root cause for them - temporarily change your MySQL logging to include all queries. That's how we ended up finding the issue.
If a connection last longer than 'interactive_timeout' limit value, will that connection get dropped automatically.
which are all connections will it drop. I mean only Sleep connections or even active connections as well?
Then what about wait_timeout variable ... ?? please explain.
interactive_timeout - The number of seconds the server waits for activity on an interactive connection before closing it.
wait_timeout - The number of seconds the server waits for activity on a noninteractive connection before closing it. This timeout applies only to TCP/IP and Unix socket file connections, not to connections made using named pipes, or shared memory.
On thread startup, the session wait_timeout value is initialized from the global wait_timeout value or from the global interactive_timeout value, depending on the type of client (as defined by the CLIENT_INTERACTIVE connect option to mysql_real_connect()).
Sleep connections and waiting connections are dropped.
For differences refer here.
I added this line to my.ini
wait_timeout=2000000
When I type
show global variables
It prints wait_timeout=2000000,
but when I type
show variables
It prints wait_timeout=28800
I can set with
set wait_timeout=2000000
But I do not want to set it all the time manually.
Do you have any suggestion to set permanently session system variable?
You probably need to check the interactive_timeout is set also - regular client connections are probably picking up your new setting, but when you check it manually using an interactive client, MySQL will set the timeout from this setting:
On thread startup, the session
wait_timeout value is initialized from
the global wait_timeout value or from
the global interactive_timeout value,
depending on the type of client (as
defined by the CLIENT_INTERACTIVE
connect option to
mysql_real_connect()). See also
interactive_timeout.
See manual for details.