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).
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.
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.
Is there any way to change value of "skip_name_resolve" variable on windows mysql server without restarting service?
This variable is not dynamic, and cannot be changed with SET query:
mysql> set global skip_name_resolve="ON";
ERROR 1238 (HY000): Variable 'skip_name_resolve' is a read only variable
The MySQL server maintains many system variables that indicate how it
is configured. Section 5.1.4, “Server System Variables”, describes the
meaning of these variables. Each system variable has a default value.
System variables can be set at server startup using options on the
command line or in an option file. Most of them can be changed
dynamically while the server is running by means of the SET statement,
which enables you to modify operation of the server without having to
stop and restart it. You can refer to system variable values in
expressions.
this is taken from http://dev.mysql.com/doc/refman/5.0/en/using-system-variables.html
ideally you should be able to change a variable by just using SET query.
MySQL has a setting called 'max_allowed_packet' which is set separately for clients and servers. On the server side it's in a config file, is it possible to set this to a non-default value on the client side when the client is rails ActiveRecord?
From the documnentation
On the client side, max_allowed_packet has a default of 1GB.
So, you just have to change it on the server side. Depending what version of MySQL you are using, you can do this on the fly on a global basis by running
SET GLOBAL max_allowed_packet=16777216
or
SET max_allowed_packet=16777216
where I assumed a 16MB max size. As you noted, you can also set the global variable in your my.cnf.
Currently, you cannot change this on a per-session basis.
mysql> SET SESSION max_allowed_packet=102400000;
ERROR 1621 (HY000): SESSION variable 'max_allowed_packet' is read-only. Use SET GLOBAL to assign the value
I dont know if could help , but you can set mysql variable at runtime .
ActiveRecord::Base.connection.execute("set global max_allowed_packet=1000000000;")
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.