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.
Related
I have an EC2 instance created with a MySQL server instance installed.
Since i am sending large blob data to be stored in the server, and the max_allowed_packet configuration is set to value 1048576, my service requests are failing.
I am trying to increase the size of the parameter to 16MB by using the below command via putty.
SET GLOBAL max_allowed_packet=16777216;
But there is no effect in the parameter. I tried restarting the sql server instance, still the effect isnt seen.
When i run the below command again after setting the parameter, the same old value is shown 1048576.
SHOW VARIABLES LIKE 'max_allowed_packet';
What am i missing here?
Update the MySQL server's configuration file /etc/my.cnf under [mysqld] section with the new value for max_allowed_packet
[mysqld]
max_allowed_packet=16M
and restart the server.
Values set via SET statement are not persisted across server restarts and are applied only on the new client sessions created after the change.
Excerpt from the documentation,
If you change a global system variable, the value is remembered and
used to initialize the session value for new sessions until you change
the variable to a different value or the server exits. The change is
visible to any client that accesses the global value. However, the
change affects the corresponding session value only for clients that
connect after the change. The global variable change does not affect
the session value for any current client sessions (not even the
session within which the global value change occurs).
We just upgraded our Mysql db from 5.6 to 5.7.21.
Then all the sql statements that are written against sql_mode:only_full_group_by gave error. That's the normal behavior of Mysql 5.7.21 because sql_mode parameter in my.ini was set to "ONLY_FULL_GROUP_BY".
Then we set this parameter to empty string ("") in my.ini and restarted server again. Everything seemed normal for just a 1 or 2 minutes , then the same queries began to give only_full_group_by error again.
We are still trying to find a solution without touching our codebase bu we couldn't yet.
You can see a live exmaple in this link
Please refreseh the page 10 times or more to get the page work.
http://www.karoltekstil.com.tr/atlet-ust-giyim/k/10-42?page=1
Each MySQL session (database connection) has its own setting for sql_mode.
When a new session is started (a new connection is made to the database), the sql_mode session variable inherits the setting of the global sql_mode setting.
While a session is running, it can change the setting of its own sql_mode, for example by issuing a statement like this:
SET ##session.sql_mode = 'ONLY_FULL_GROUP_BY' ;
The new value of sql_mode remains in effect for that session, until it is changed again, or until the session ends.
A user with sufficient privilege can also change the global setting of sql_mode, with a statement like this for example:
SET ##global.sql_mode = 'ONLY_FULL_GROUP_BY' ;
Any change made the global setting only affects new sessions (connections started after the change is applied.) Changes to the global setting don't influence sessions that are already started. The existing sessions already have their "copy" of sql_mode that was inherited when the connection was started.
Note that ONLY_FULL_GROUP_BY can be explicit in sql_mode, or it can be included implicitly in a combination setting. For example, sql_mode='ANSI' includes ONLY_FULL_GROUP_BY.
MySQL startup has a variety of locations that it reads configuration information from, whether that's my.ini, my.cnf, or options provided on the command line of the startup.
Next steps in debugging this is to determine if sql_mode is being set properly when the database starts, and then determine if there are statements being executed in individual sessions that change the setting of sql_mode.
Is the application churning database connections, starting and ending discrete sessions?
Or is the application using a connection pool, persistent connections that are borrowed and returned from the pool?
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.
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.
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.