关于max_allowed_packet这个值设置后自动重置问题

系统linux
mysql版本是5.0.95
在my.cnf里设置max_allowed_packet=16M后,重启后查看这个值也确实变成了16M

但过个1,2天后插入数据报错了,后来查看这个值又变成了默认的1024 为啥呢?看日志mysql中间也没重启过
请各位大神分析下原因

80 个解决方案

#1

如果确认 重启后查看这个值也确实变成了16M

应该不会出现自动修改的问题

如果写在正确的my.cnf中后，重启也不会影响 


很有可能是人为改过

#2

肯定是被改掉了。

#3

昨天晚上刚改的,今早一看,又变成1024了.my.cnf这个文件没被改,现在只要重启mysql就编程16M.但不知道怎么就变成了1024呢了???没人改啊~

#4

引用 2 楼 ACMAIN_CHM 的回复:

肯定是被改掉了。

真没人改,我看登陆记录,没人登陆过.

#5

引用 1 楼 benluobobo 的回复:

如果确认 重启后查看这个值也确实变成了16M

应该不会出现自动修改的问题

如果写在正确的my.cnf中后，重启也不会影响 


很有可能是人为改过

改完my.cnf文件 重启确实变成了16M  能持续个一天,但第二天就变回去了.查看my.cnf里面也还是写有16M的.但查看那个值却为1024.非常诡异啊!!!

#6

我也遇到同样的问题，这个值自动变回了1024 导致失败。请问找到什么原因了没？

#7

检查你的MYSQL本身，是不是每天安排了什么自行启动之类的。

MYSQL如果在正常运行中是不会改变这个参数的。一定是有人在操作系统上做了什么，比如修改了文件，重启了系统但指定的是其它参数文件。 可以导致这个现象的方法很多。

#8

楼主解决问题了吗？

#9

我也遇到了这样的问题，my.cnf里面还是设置的32M，但是查看变成了1024.

因为数据库是共用的，我只知道我在这期间仅仅是通过客户端新建了一张表，同事有没有做其他操作不清楚~~目前原因还未知。

楼主要是找到原因了记得@我下，谢谢~~

#10

看看是不是有人通过set global的方式设置了这个值？

#11

我也遇到了这个问题啊，好奇怪啊

#12

我这两天刚好遇到了 http://www.2cto.com/database/201303/195830.html    用set global max_allowed_packet = 4*1024*1024设置每次重启机器他都会重新设置   除非你改my.ini 文件

#13

引用 1 楼 benluobobo 的回复:

如果确认 重启后查看这个值也确实变成了16M

应该不会出现自动修改的问题

如果写在正确的my.cnf中后，重启也不会影响 


很有可能是人为改过

  服务器是自己公司的还是买的人家的  买的人家的有可能别人晚上维护之类的吧  你刚好赶上了

#14

遇到了同样的问题

#15

我也是遇到同样问题啊，服务器的管理权限只有我有，不放心我还改了下SSH的密码，可是又出现max_allowed_packet自动恢复成1024的情况了，头疼。哪位兄弟找到原因了请告知下，谢过了！

#16

max_allowed_packet 和innodb_buffer_pool_size 
这些参数不是你设多少就是多少
innodb_buffer_pool_size  设成内存50%
你查看一下状态值不是你设置的值 ，这是一个最高值
1024 也是当前用的值 最大到16*1024*1024

#17

我也遇到同样的问题，求解!! [e-mail]

#18

请问解决了吗？ 是因为mysql内存不足，被重置了吗？ 有方法复现吗？ 楼主

#19

遇到同样的问题，有解决方法没？

#20

遇到同样的问题，有解决方法没？

#21

同样遇到 。无解决方案……求问

#22

楼主，解决了吗？现在遇到同样的问题……

#23

楼主，解决了吗？现在遇到同样的问题……  

#24

特码 原来是 数据库所在服务器内存不够用被mysql重置了； 希望我的回答对以后遇到此问题的人有帮助

#25

数据库所在服务器内存不够用----------那怎么解决呢？

#26

引用 24 楼 oWangChuan123456 的回复:

特码 原来是 数据库所在服务器内存不够用被mysql重置了； 希望我的回答对以后遇到此问题的人有帮助

咋解决的呢？

#27

引用 13 楼 u013810758 的回复:

Quote: 引用 1 楼 benluobobo 的回复:

如果确认 重启后查看这个值也确实变成了16M

应该不会出现自动修改的问题

如果写在正确的my.cnf中后，重启也不会影响 


很有可能是人为改过

  服务器是自己公司的还是买的人家的  买的人家的有可能别人晚上维护之类的吧  你刚好赶上了

你看是不是系统内存不够用了被重置了  我之前遇到是内存不够用了

#28

也遇到这个问题，请问解决了吗？

#29

http://blog.chinaunix.net/uid-20304801-id-1707731.html

#30

引用 29 楼 u013810758 的回复:

http://blog.chinaunix.net/uid-20304801-id-1707731.html

 MySQL 的max_allowed_packet保护导致MySQL Server 不断的启停 2007-03-03 16:56:42
分类： Mysql/postgreSQL
昨天晚上一位客户反映，他的PHP-MySQL程序突然不能正常访问。检查服务器，发现这是一台一直以来运行很稳定的服务器，以前并没有发生过什么问题的，特别是在mysql与php方面。

按客户提供的页面进行访问，觉得很奇怪：不能正常访问是很有规律的出现的，MySQL连接出错是相互交替，即一次能正常连接，生成页面，那下一次就是不能连接，生成页面,显示的错误为：
     Error No. 2003: Can't connect to MySQL server on 'localhost' (or some other host)
一看这信息，应该是MySQL死掉的现象！查看系统日志，MySQL的shutdown 与 startup的时间确实与访问页面的时间可以对应。
(后记：其实出现这个提示的原因，可能有以下三种
    1. 服务器没有运行MySQL Server或shutdown了；
    2. MySQL Server不接受TCP/IP连接请求。查看配置文件中的skip-networking有没有被禁掉；
    3. 其它网络的问题。)

那到底是什么原因造成MySQL死掉又启来呢？

如果MySQL能够正常自动启动，那访问这个页面对MySQL的影响是数据库系统可以自动识别出来的，出于一种自动保护的原因，它才会shutdown MySQL. 

基于以上的原因，开始查找资料，看都有在哪些情况下MySQL会自动shutdown后又立即startup的。
  
首先想到的是buffer(read,sort,temp etc.)不足，那么修改配置文件，把它们都增大一倍后重启MySQL，还是同样的会死掉。

接下来想到的就是可能请求的连接包过大，检查配置文件，其中并没有max_allowed_packet声明。在配置文件中，设置max_allowed_packet=2M后，重新启动MySQL，问题解决！

呵呵，看来mysql的配置文件中还有很多内容可挖的哟，以后得多多注意了。

#31

请问现在解决了么》怎么破

#32

确实是个问题，先加点内存试一下。

#33

引用 32 楼 xin1384233 的回复:

确实是个问题，先加点内存试一下。

哥们 怎么加内存？在my.cnf里修改？？跪求指导 

#34

之前我也遇到这个问题~~  百思不得其解~ 后来开启了mysql的查询日志general_log_file 发现了我的myql出现这个问题的所在。（源于黑客攻击）某些时刻一个莫名的ip登录我的mysql 然后利用mysql的udf来更改一些参数~ 包括max_allowed_packet=1024的设置~后来处理的方案是限制ip登录~~其实更简单的可以直接关掉mysql的udf功能。希望对大家有所帮助~~

#35

引用 24 楼 oWangChuan123456 的回复:

特码 原来是 数据库所在服务器内存不够用被mysql重置了； 希望我的回答对以后遇到此问题的人有帮助

哥们这个问题解决了吗？如何解决的

#36

哥们，你解决这个问题了吗？我也遇到了，在ubuntu的mysql 5.5版本，没有这个问题，在centos6.4上用rpm 安装的 mysql5.1版本没有这个问题，但是我按照网上的centos6.4    cmake编译安装mysql5.5版本 就有这个问题。。。。。我用的是云服务器

#37

已经解决了，liyili.me

#38

引用 37 楼 qq_19400243 的回复:

已经解决了，liyili.me

请问是怎么解决的!

#39

同样求答案，服务器内存还很大啊

#40

楼主你好
        重新设置My.ini里面的参数，然后在[mysqld] 下面添加下面的语句

          max_allowed_packet=500M

        然后重启MySQL，应该就没问题了，
   想了解的更详细的话，请参考下面的文档
https://dev.mysql.com/doc/refman/5.5/en/packet-too-large.html

#41

引用 37 楼 qq_19400243 的回复:

已经解决了，liyili.me

次奥，解决了，不贴方案

#42

哈哈，终于解决了，解决办法让我大跌眼睛，妈蛋，直接修改下MYSQL密码即可，不要用root密码，我修改了密码后，已经正常运行了4天了，之前不管怎么修改max_allowed_packet这个值，第二天绝对会初始为1024，现在就不会了初始化了。大家还有这样的问题的可以试着修改下密码，我现在不知道后边还会不会重置为1024，先看下再说！如果没有解决你们的问题请别喷我！嘿嘿，我也要再观察下，我的是centos 6.5中的mysql-5.7.10-1.el6.x86_64.rpm-bundle.tar 版本！！

#43

引用 42 楼 lcydlyy7 的回复:

哈哈，终于解决了，解决办法让我大跌眼睛，妈蛋，直接修改下MYSQL密码即可，不要用root密码，我修改了密码后，已经正常运行了4天了，之前不管怎么修改max_allowed_packet这个值，第二天绝对会初始为1024，现在就不会了初始化了。大家还有这样的问题的可以试着修改下密码，我现在不知道后边还会不会重置为1024，先看下再说！如果没有解决你们的问题请别喷我！嘿嘿，我也要再观察下，我的是centos 6.5中的mysql-5.7.10-1.el6.x86_64.rpm-bundle.tar 版本！！

不行。。。。。怒了！！！！昨天又重置了1024了。。。。。大神！！！

#44

请问是否解决，从昨天开始，我们服务器也开始出现这种情况。正常情况下有5g的内存空闲。感觉并不是内存不足的问题，如果是也只是峰值内存不足。但是为什么mysql会自己修改这个值？有解决方案后希望大家回复下。

#45

最近也是遇到了这个问题，直到昨天才找到原因，并不是服务器内存的问题，而是被人为的修改了。前天我把mysql的通用日志打开跟踪了一天，昨天仔细看了一下日志文件，才发现被莫名的ip攻击了，对方一直不停的尝试密码进入数据库，进入之后修改了参数，当然不但修改参数，还下载了一些病毒软件，现在想想都可怕。希望遇到此问题的朋友可以打开general_log，跟踪一下，看看是不是遇到了同样的事情，建议修改数据库的密码，而且一定要是强密码，否则还是可能被攻破。

#46

莫名ip攻入之后开始干坏事


希望大家引以为戒啊。

#47

引用 24 楼 oWangChuan123456 的回复:

特码 原来是 数据库所在服务器内存不够用被mysql重置了； 希望我的回答对以后遇到此问题的人有帮助

原因不是这个，原来和内存没关系。 

#48

应该就是被人攻击了，我这也出现了，我看了一下回答，最近这个问题有些集中！准有人用爬虫修改

#49

我的也是，这个值一直恢复成1024

#50

我这里也是被攻击了，ip访问限制一下吧，或者换个密码啥的