I have my application hosted on a shared server, I can't access my.cnf/my.ini file from my account, max_allowed_packet is set to 1M only, Now I need to change it to 32M, is their any idea either by PHP or .htaccess to change its value?
Thanks and Regards
Prajjwal
max_allowed_packet allowed for dynamic values, that's mean you just need to login to mysql console
show variables like 'max_allowed_packet';
set global max_allowed_packet=33554432;
logout, and login again
show variables like 'max_allowed_packet';
If you do not have the console login, try PHP should work the same way.
Related
Have created a mysql server which has somehow log_bin set to ON and enforce_gtid_consistency is also set to ON. Now this is causing few issues in my case and i want to turn OFF those variables.
Process i have tried
1. Create a .my.cnf file in user root (~/.my.cnf) and added
[mysqld]
enforce_gtid_consistency=OFF
Result: No changes. It doesnt take effect.
2. In azure portal in init_connect variable i have set "SET enforce_gtid_consistency=OFF;" (because there is no mention of this variable in server parameters).
Result: Cant connect to mysql after setting up value in this parameter.
Is there any way we can fix this?
May be the following doc is helpful:
https://learn.microsoft.com/en-us/azure/mysql/concepts-read-replicas#global-transaction-identifier-gtid
Once GTID is enabled, you cannot turn it back off. If you need to turn GTID OFF, please contact support.
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).
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.
This question already has answers here:
How to change max_allowed_packet size
(14 answers)
Closed 1 year ago.
I found out how to change the default value of max_allowed_packet in MySQL using SET GLOBAL. However, each time I used this command, the default value stayed untouched!
I used these commands:
mysql --user=root --password=mypass
mysql> SET GLOBAL max_allowed_packet=32*1024*1024;
Query OK, 0 rows affected (0.00 secs)
mysql> SHOW VARIABLES max_allowed_packet;
And then the result is max_allowed_packet = 1048576. What am I missing?
Hmmmm.. You have hit this NOT-A-BUG it seems. :)
If you change a global system variable, the value is remembered and used for new
connections until the server restarts. (To make a global system variable setting
permanent, you should set it in an option file.) The change is visible to any client that
accesses that global variable. However, the change affects the corresponding session
variable only for clients that connect after the change. The global variable change does
not affect the session variable for any client that is currently connected (not even that
of the client that issues the SET GLOBAL statement).
Refer this too. Read Shane Bester explanation.
You should change from the my.ini/my.cnf file and restart the server for the max_allowed_packet setting to take effect.
After running
set global max_allowed_packet=1000000000;
you have to restart mysql before
SHOW VARIABLES LIKE 'max_allowed_packet'
will show the new value.
I have this issue when restarting mysql through the MAC OSX system preferences and the value hadn't changed. So by logging into mysql via console
mysql -u root -p
changing it and then restarting mySql seemed to work. Might have been a OS X quirk though.
For those with a MariaDb configuration the problem could be that the max_allowed_packet variable is overwritten by a configuration file called later.
In my case I tried to import a database and the server answered me:
ERROR 2006 (HY000) at line 736: MySQL server has gone away
I discovered that the file:
/etc/mysql/mariadb.conf.d/50-server.cnf
is called later
/etc/mysql/conf.d/mysql.cnf
I tried continuously changing in the "mysql.cnf" file but the value was overwritten in "50-server.cnf".
So the solution is to enter the file
/etc/mysql/mariadb.conf.d/50-server.cnf
and instead of
"max_allowed_packet = 16M"
put the desired value as an example
"max_allowed_packet = 64M"
I came across this problem as well and in my case I have multiple versions of MySql installed.
Adding this note for anyone who might have setup MySql using homebrew on mac and are having trouble setting max_allowed_packet value in your my.cnf file.
The most key information that helped was that the my.cnf file can be present in different locations (excerpt from https://github.com/rajivkanaujia/alphaworks/wiki/Install-MySQL-using-Homebrew) -
/usr/local/etc/my.cnf --> Global Access
/usr/local/etc/my.cnf --> Global Access
/usr/local/Cellar/mysql/5.7.18/my.cnf --> Sever Level Access
~/.my.cnf --> User Level Access
Since I installed MySql 5.6 via Home brew I found it at -
/usr/local/Cellar/mysql\#5.6/5.6.43/my.cnf
Steps followed -
Update the /usr/local/Cellar/mysql\#5.6/5.6.43/my.cnf file under [mysqld] group with the necessary max_allowed_packet value -
[mysqld]
max_allowed_packet=5G
Restart mysql using brew services -
brew services restart mysql#5.6
Connect/Reconnect to the mysql shell and verify that the configuration has taken effect using -
show variables like 'max_allowed_packet';
Just a quick way to see the variable for anybody who comes across this. To get the value back you need to run
SHOW VARIABLES LIKE 'max_allowed_packet'
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.