I set
SET GLOBAL max_allowed_packet=16777216;
and also
[mysqld]
max_allowed_packet = 16M
I checked the max_allowed_packet through below command
我通过下面的命令检查了max_allowed_packet
SHOW VARIABLES LIKE 'max_allowed_packet';
and the value is = 16777216
值为= 16777216
But after some days max_allowed_packet automatically reset to 1M.
但是几天后max_allowed_packet会自动重置为1M。
6 个解决方案
#1
6
i am pretty sure that your are hacked. i had the same problem for months. i opened general_log and finally found some codes:
我很确定你被黑了。我好几个月都有同样的问题。我打开了general_log,最后找到了一些代码:
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.
建议:更改root密码。
#2
1
MySQL has both GLOBAL variables and SESSION variables, as well as the my.cnf.
MySQL既有GLOBAL变量,也有SESSION变量,以及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.
GLOBAL变量在启动时从my.cnf初始化,并且许多变量在连接时从GLOBAL值获取并复制到SESSION中。如果更改GLOBAL值,则SESSION会保留其自身的值 - 但任何新会话都将采用新的GLOBAL默认值。
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.
看来你在设置GLOBAL变量和更新my.cnf方面做了正确的事情,但在你的例子中你运行了“SHOW VARIABLES”,它返回了SESSION值。因此,在这种情况下你可能没有检查正确的值。我建议您在将来检查时检查全局和会话值,以帮助了解何时发生变化。
SHOW GLOBAL VARIABLES LIKE 'max_allowed_packet'; SHOW SESSION VARIABLES LIKE 'max_allowed_packet';
显示全局变量类似'max_allowed_packet';显示会话变量类似'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
(1)您正在重新使用仍具有旧值的会话(2)另一个连接已运行SET GLOBAL max_allowed_packet,甚至有些无法使用的应用程序或脚本正在执行此操作(3)服务器已重新启动,并且my.cnf更改未按预期应用 - 可能是文件路径错误,或者配置文件中的设置存在多次。我将检查SHOW GLOBAL STATUS中的当前Uptime以了解服务器是否已重新启动
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.
我想不出有任何其他原因会发生这种情况。我确实检查了当你传递--max_allowed_packet时客户端是否协商服务器端值,但事实并非如此。
#3
1
Yes, someone hack the system.I changed the root password and everything working fine.
是的,有人破解了系统。我更改了root密码,一切正常。
#4
0
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.
默认情况下,MySQL中的max_allowed_packet值为1M。我相信你的“max_allowed_packet”的大小超过了它的上限。所以,当你检查“SHOW VARIABLES LIKE'max_allowed_packet';”它显示出一些负面价值。
Additionally,
You have two values of max_allowed_packet in MySQL :
MySQL中有两个max_allowed_packet值:
one on the client side : [mysql] section, [mysqldump], [client] and more. one on the server side : [mysqld] section.
一个在客户端:[mysql]部分,[mysqldump],[客户端]等。一个在服务器端:[mysqld]部分。
#5
0
Try setting 'Super' privilege of all users to 'N', except 1 admin user. This prevents users from changing max_allowed_packet.
尝试将所有用户的“超级”权限设置为“N”,但1位管理员用户除外。这可以防止用户更改max_allowed_packet。
#6
0
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.
那些试图弄清楚黑客是否是他们的根本原因的人提示 - 暂时更改您的MySQL日志记录以包含所有查询。这就是我们最终找到问题的方式。
#1
6
i am pretty sure that your are hacked. i had the same problem for months. i opened general_log and finally found some codes:
我很确定你被黑了。我好几个月都有同样的问题。我打开了general_log,最后找到了一些代码:
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.
建议:更改root密码。
#2
1
MySQL has both GLOBAL variables and SESSION variables, as well as the my.cnf.
MySQL既有GLOBAL变量,也有SESSION变量,以及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.
GLOBAL变量在启动时从my.cnf初始化,并且许多变量在连接时从GLOBAL值获取并复制到SESSION中。如果更改GLOBAL值,则SESSION会保留其自身的值 - 但任何新会话都将采用新的GLOBAL默认值。
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.
看来你在设置GLOBAL变量和更新my.cnf方面做了正确的事情,但在你的例子中你运行了“SHOW VARIABLES”,它返回了SESSION值。因此,在这种情况下你可能没有检查正确的值。我建议您在将来检查时检查全局和会话值,以帮助了解何时发生变化。
SHOW GLOBAL VARIABLES LIKE 'max_allowed_packet'; SHOW SESSION VARIABLES LIKE 'max_allowed_packet';
显示全局变量类似'max_allowed_packet';显示会话变量类似'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
(1)您正在重新使用仍具有旧值的会话(2)另一个连接已运行SET GLOBAL max_allowed_packet,甚至有些无法使用的应用程序或脚本正在执行此操作(3)服务器已重新启动,并且my.cnf更改未按预期应用 - 可能是文件路径错误,或者配置文件中的设置存在多次。我将检查SHOW GLOBAL STATUS中的当前Uptime以了解服务器是否已重新启动
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.
我想不出有任何其他原因会发生这种情况。我确实检查了当你传递--max_allowed_packet时客户端是否协商服务器端值,但事实并非如此。
#3
1
Yes, someone hack the system.I changed the root password and everything working fine.
是的,有人破解了系统。我更改了root密码,一切正常。
#4
0
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.
默认情况下,MySQL中的max_allowed_packet值为1M。我相信你的“max_allowed_packet”的大小超过了它的上限。所以,当你检查“SHOW VARIABLES LIKE'max_allowed_packet';”它显示出一些负面价值。
Additionally,
You have two values of max_allowed_packet in MySQL :
MySQL中有两个max_allowed_packet值:
one on the client side : [mysql] section, [mysqldump], [client] and more. one on the server side : [mysqld] section.
一个在客户端:[mysql]部分,[mysqldump],[客户端]等。一个在服务器端:[mysqld]部分。
#5
0
Try setting 'Super' privilege of all users to 'N', except 1 admin user. This prevents users from changing max_allowed_packet.
尝试将所有用户的“超级”权限设置为“N”,但1位管理员用户除外。这可以防止用户更改max_allowed_packet。
#6
0
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.
那些试图弄清楚黑客是否是他们的根本原因的人提示 - 暂时更改您的MySQL日志记录以包含所有查询。这就是我们最终找到问题的方式。