欢迎各位兄弟 发布技术文章

这里的技术是共享的

You are here

首页

MySQL数据库关于一次导入数据提示的MySQL server has gone away 自己亲自做的 有大用 有大大用

shiping1 的头像
星期一, 2013-09-09 00:39 — shiping1

 

MySQL数据库关于一次导入数据提示的MySQL server has gone away

背景        

这个问题由一个同事问到的一次导入数据引发。一个很常见的操作，将数据从一个表中dump出来，在用mysql < a.sql的方式导入到另一个库的一个表中。

在执行导入的时候，提示 MySQL server has gone away。在追查的时候突然想到会不会是因为max_allowed_packet太小导致的。将max_allowed_packet改大，确实解决了问题。

(史平忠的方法是修改my.ini 的 max_allowed_packet 为 20M,然后重启mysql服务器,问题解决)       

在 drupal drupal7 d7 中 把 max_allowed_packet 为 512M 才行,,,哎不怎么回事


 

本文基于在此之后想到的两个问题：

1、              MySQL server has gone away这个提示很不友好，是不是所有的包超过大小都是报这个？

2、              对于出现这种不友好的错误提示，有什么方法定位原因（而不是靠“突然想到”）？

追查1        

步骤：a) 把max_allowed_packet设置为一个比较小的值， set global max_allowed_packet=16384

b) 写一个简单的语句 insert into tb values(xxx),(xxx),(xxx)……(xxx) 让这个文件足够大，比如我测试使用 a.sql大小为37318

c) 执行导入语句，提示 ER2ROR 1153 (08S01) at line 1: Got a packet bigger than ‘max_allowed_packet’ bytes

初步结论是并不是所有的语句太大都会导致直接显示gone away。如果都是后面这个提示就好了，一目了然，用户自然会去修改max_allowed_packet。

因此我们的问题就变成：为什么会有不同的提示？

分析1        

  我们将报gone away的称为场景1，另外一个称为场景2.

场景1执行的sql语句大小是16554913

实际上场景2的返回信息是由MySQL服务端返回的，因为服务端才能判断得到包大小超过。那么场景1为什么不是相同的提示呢？是不是压根儿请求就没有发到服务端？

照这个思路查到下面代码(clent/mysql.cc)

       

其中场景1执行到2785行return了，而场景2是在调用2786行的put_error中输出上述信息的。

这证实了上面的结论，场景1是在调用请求的时候提示的失败，还没有到服务端判断包大小的环节。但是问题又来了，发送失败为什么要提示gone away呢？我们最常见到的gone away，是执行期间MySQL重启了，但这个case里面mysql并没有重启（这个很容易确认）。

分析1-2        

进到mysql_real_query里面看看。发现执行路径差别在此(sql-common/client.c)

       

场景1调用net_write_command失败，会执行到行854，场景2调用成功。就是说场景2里面，整个语句是都发给服务端成功的，因此服务端可以做后续的判断（包大小）。而场景1由于发命令失败，执行到mysql_reconnect.。但进入mysql_reconnect发现没有必要重发（我们是普通的客户端），然后发现一处hard code。

       

这里就是罪魁祸首了。因为mysql->reconnect为空，说明这里不需要重新连接。于是就直接在set_mysql_error中传入 CR_SERVER_GONE_ERROR, 输出在客户端就是gone away。

至于为什么场景1发送会失败，关键就是内容太大，tcp都不让它发了(write调用失败)

追查2        

其实笔者觉得这个问题反而比较有意义，gone away这种错误提示不友好，会导致追查很难下手。有一个固定的步骤来查，避免抓瞎。

从上面的分析知道，由于之前的调用失败，客户端试图进行“重连”，但是由于mysql->reconnect为0导致返回gone away。可以从这里下手。获取在执行mysql_reconnect之前的那个错误号。

一个debug命令文件

[dingqi.lxb@rds064076 master]$ cat x.debug

set args   -Srun/mysql.sock -uroot   test < b.sql
b mysql_reconnect
r
c
f 1
p mysql->net.last_errno

在shell执行 gdb mysql  -x x.debug
$1 = 1160

这个1160就是我们要的了，

./include/mysqld_ername.h:{ “ER_NET_ERROR_ON_WRITE”, 1160, “Got an error writing communication packets” },

表明了真正的错误是交互时发包失败。

小结        

都是包太大，只是一个大过头了，导致在失败在客户端发生，又由于重连时的hard code，导致了一个不友好的提示 gone away。

神马？你也碰到这种情况但不是max_allowed_packet 的问题，但是你的mysql没有debug信息？载一个源码安装。或者可以将你的复现步骤发给我。#异常gone away收集中#

 

原创文章，转载请注明： 文章地址MySQL数据库关于一次导入数据提示的MySQL server has gone away            

订阅本站：http://feed.mysqlops.com   转载请注明来源，如果喜欢本站可以Feed 订阅本站。

Filed under Internal · Tagged with , ,             

About 丁奇
围脖 @淘宝丁奇

Comments

2 Responses to “MySQL数据库关于一次导入数据提示的MySQL server has gone away”        
  1. johnny0924 说道：                    
    2012 年 12 月 13 日 下午 4:24                    

    控制好mysqldump的net_buffer_length可以避免这个问题出现
    http://dev.mysql.com/doc/refman/5.5/en/mysqldump.html#option_mysqldump_net_buffer_length                    

    回复                    

Trackbacks

Check out what others are saying about this post...        
  1. DBA_MYSQL_LINUX_Perl » 导入数据提示的MySQL server has gone away[转] 说道：                    
    2013 年 01 月 16 日 上午 10:41                    

    [...] 原文地址：http://www.mysqlops.com/2012/12/13/%E5%85%B3%E4%BA%8E%E4%B8%80%E6%AC%A1%E5%AF%BC%E5%85%A5%E6%95%B0%E… [...]

     

    来自 http://www.mysqlops.com/2012/12/13/%E5%85%B3%E4%BA%8E%E4%B8%80%E6%AC%A1%E5%AF%BC%E5%85%A5%E6%95%B0%E6%8D%AE%E6%8F%90%E7%A4%BA%E7%9A%84mysql-server-has-gone-away.html                    

     

     

     

     

     

     

     

    #2006 - MySQL server has gone away 问题解决方法                    

    1、应用程序（比如PHP）长时间的执行批量的MYSQL语句。
    最常见的就是采集或者新旧数据转化。
                               

    解决方案：

    在my.ini文件中添加或者修改以下两个变量：
    wait_timeout=2880000
    interactive_timeout = 2880000

    关于两个变量的具体说明可以google或者看官方手册。
    如果不能修改my.cnf，则可以在连接数据库的时候设置CLIENT_INTERACTIVE，比如：
    sql = "set interactive_timeout=24*3600";
    mysql_real_query(...)

    2、执行一个SQL，但SQL语句过大或者语句中含有BLOB或者longblob字段。
    比如，图片数据的处理
    解决方案

    在my.cnf文件中添加或者修改以下变量：
    max_allowed_packet = 10M  (也可以设置自己需要的大小)

    max_allowed_packet 参数的作用是，用来控制其通信缓冲区的最大长度。

    －－－－－－－－－－－－ 以下是网络搜索的资料 －－－－－－－－－－－－－－－－－－－


    也许其他人遇到这个问题，不一定是这儿的原因，那么，就把我在网上找到比较全面的分析放到下面：
    有两篇，第一篇比较直观，第二篇比较深奥。
    解决MySQL server has gone away 2009-01-09 16:23:22
    来自：http://www.webjx.com/database/mysql-8817.html
    今天遇到类似的情景，MySQL只是冷冷的说：MySQL server has gone away。
    大概浏览了一下，主要可能是因为以下几种原因：
    一种可能是发送的SQL语句太长，以致超过了max_allowed_packet的大小，如果是这种原因，你只要修改my.cnf，加大max_allowed_packet的值即可。
    还有一种可能是因为某些原因导致超时，比如说程序中获取数据库连接时采用了Singleton的做法，虽然多次连接数据库，但其实使用的都是同一个连接，而且程序中某两次操作数据库的间隔时间超过了wait_timeout（SHOW STATUS能看到此设置），那么就可能出现问题。最简单的处理方式就是把wait_timeout改大，当然你也可以在程序里时不时顺手mysql_ping()一下，这样MySQL就知道它不是一个人在战斗。
    解决MySQL server has gone away

    1、应用程序（比如PHP）长时间的执行批量的MYSQL语句。最常见的就是采集或者新旧数据转化。

    解决方案：

    在my.cnf文件中添加或者修改以下两个变量：

    wait_timeout=2880000
    interactive_timeout = 2880000　　
    关于两个变量的具体说明可以google或者看官方手册。如果不能修改my.cnf，则可以在连接数据库的时候设置CLIENT_INTERACTIVE，比如：

    sql = "set interactive_timeout=24*3600";
    mysql_real_query(...)

    2、执行一个SQL，但SQL语句过大或者语句中含有BLOB或者longblob字段。比如，图片数据的处理

    解决方案：

    在my.cnf文件中添加或者修改以下变量：

    max_allowed_packet = 10M
    (也可以设置自己需要的大小)

    max_allowed_packet
    参数的作用是，用来控制其通信缓冲区的最大长度

    MySQL: 诡异的MySQL server has gone away及其解决
    来自：http://fz9493.blog.sohu.com/38472203.html

    jimmy | 15 三月, 2007 20:32

    在Mysql执行show status，通常更关注缓存效果、进程数等，往往忽略了两个值：

    Variable_name Value 
    Aborted_clients 3792 
    Aborted_connects 376


    通常只占query的0.0x%，所以并不为人所重视。而且在传统Web应用上，query错误对用户而言影响并不大，只是重新刷新一下页面就OK了。最近的基础改造中，把很多应用作为service运行，无法提示用户重新刷新，这种情况下，可能就会影响到服务的品质。

    通过程序脚本的日志跟踪，主要报错信息为“MySQL server has gone away”。官方的解释是：

    The most common reason for the MySQL server has gone away error is that the server timed out and closed the connection.

    Some other common reasons for the MySQL server has gone away error are:

    You (or the db administrator) has killed the running thread with a KILL statement or a mysqladmin kill command.

    You tried to run a query after closing the connection to the server. This indicates a logic error in the application that should be corrected.

    A client application running on a different host does not have the necessary privileges to connect to the MySQL server from that host.

    You got a timeout from the TCP/IP connection on the client side. This may happen if you have been using the commands: mysql_options(..., MYSQL_OPT_READ_TIMEOUT,...) or mysql_options(..., MYSQL_OPT_WRITE_TIMEOUT,...). In this case increasing the timeout may help solve the problem.

    You have encountered a timeout on the server side and the automatic reconnection in the client is disabled (the reconnect flag in the MYSQL structure is equal to 0).

    You are using a Windows client and the server had dropped the connection (probably because wait_timeout expired) before the command was issued.

    The problem on Windows is that in some cases MySQL doesn't get an error from the OS when writing to the TCP/IP connection to the server, but instead gets the error when trying to read the answer from the connection.

    In this case, even if the reconnect flag in the MYSQL structure is equal to 1, MySQL does not automatically reconnect and re-issue the query as it doesn't know if the server did get the original query or not.

    The solution to this is to either do a mysql_ping on the connection if there has been a long time since the last query (this is what MyODBC does) or set wait_timeout on the mysqld server so high that it in practice never times out.

    You can also get these errors if you send a query to the server that is incorrect or too large. If mysqld receives a packet that is too large or out of order, it assumes that something has gone wrong with the client and closes the connection. If you need big queries (for example, if you are working with big BLOB columns), you can increase the query limit by setting the server's max_allowed_packet variable, which has a default value of 1MB. You may also need to increase the maximum packet size on the client end. More information on setting the packet size is given in Section A.1.2.9, “Packet too large”.

    An INSERT or REPLACE statement that inserts a great many rows can also cause these sorts of errors. Either one of these statements sends a single request to the server irrespective of the number of rows to be inserted; thus, you can often avoid the error by reducing the number of rows sent per INSERT or REPLACE.

    You also get a lost connection if you are sending a packet 16MB or larger if your client is older than 4.0.8 and your server is 4.0.8 and above, or the other way around.

    It is also possible to see this error if hostname lookups fail (for example, if the DNS server on which your server or network relies goes down). This is because MySQL is dependent on the host system for name resolution, but has no way of knowing whether it is working — from MySQL's point of view the problem is indistinguishable from any other network timeout.

    You may also see the MySQL server has gone away error if MySQL is started with the --skip-networking option.

    Another networking issue that can cause this error occurs if the MySQL port (default 3306) is blocked by your firewall, thus preventing any connections at all to the MySQL server.

    You can also encounter this error with applications that fork child processes, all of which try to use the same connection to the MySQL server. This can be avoided by using a separate connection for each child process.

    You have encountered a bug where the server died while executing the query.



    据此分析，可能原因有3：

    1，Mysql服务端与客户端版本不匹配。

    2，Mysql服务端配置有缺陷或者优化不足

    3，需要改进程序脚本

    通过更换多个服务端与客户端版本，发现只能部分减少报错，并不能完全解决。排除1。

    对服务端进行了彻底的优化，也未能达到理想效果。在timeout的取值设置上，从经验值的10，到PHP默认的60，进行了多次尝试。而Mysql官方默认值(8小时)明显是不可能的。从而对2也进行了排除。(更多优化的经验分享，将在以后整理提供)

    针对3对程序代码进行分析，发现程序中大量应用了类似如下的代码(为便于理解，用原始api描述)：

    $conn=mysql_connect( ... ... );

    ... ... ... ...

    if(!$conn){ //reconnect

    $conn=mysql_connect( ... ... );

    }

    mysql_query($sql, $conn);

    这段代码的含义，与Mysql官方建议的方法思路相符[ If you have a script, you just have to issue the query again for the client to do an automatic reconnection. ]。在实际分析中发现，if(!$conn)并不是可靠的，程序通过了if(!$conn)的检验后，仍然会返回上述错误。

    对程序进行了改写：

    if(!conn){ // connect ...}

    elseif(!mysql_ping($conn)){ // reconnect ... }

    mysql_query($sql, $conn);

    经实际观测，MySQL server has gone away的报错基本解决。

    BTW： 附带一个关于 reconnect 的疑问，

    在php4x+client3x+mysql4x的旧环境下，reconnet的代码：

    $conn=mysql_connect(...) 可以正常工作。

    但是，在php5x+client4x+mysql4x的新环境下，$conn=mysql_connect(...)返回的$conn有部分情况下不可用。需要书写为：

    mysql_close($conn);

    $conn=mysql_connect(...);

    返回的$conn才可以正常使用。原因未明。未做深入研究，也未见相关讨论。或许mysql官方的BUG汇报中会有吧。

    ～～呵呵～～


    本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/brightsnow/archive/2009/03/17/3997705.aspx


    description: 
    remember that your MySQL "max_allowed_packet" configuration setting (default 1MB) 
    mysql 默认最大能够处理的是1MB 
    如果你在sql使用了大的text或者BLOB数据，就会出现这个问题。 php手册上的注释 

    When trying to INSERT or UPDATE and trying to put a large amount of text or data (blob) into a mysql table you might run into problems. 
    In mysql.err you might see: 
    Packet too large (73904) 
    To fix you just have to start up mysql with the option -O max_allowed_packet=maxsize 
    You would just replace maxsize with the max size you want to insert, the default is 65536 


    mysql手册上说 

    Both the client and the server have their own max_allowed_packet variable, so if you want to handle big packets, you must increase this variable both in the client and in the server. 

    If you are using the mysql client program, its default max_allowed_packet variable is 16MB. To set a larger value, start mysql like this: 

    shell> mysql --max_allowed_packet=32M That sets the packet size to 32MB. 

    The server's default max_allowed_packet value is 1MB. You can increase this if the server needs to handle big queries (for example, if you are working with big BLOB columns). For example, to set the variable to 16MB, start the server like this: 

    shell> mysqld --max_allowed_packet=16M You can also use an option file to set max_allowed_packet. For example, to set the size for the server to 16MB, add the following lines in an option file: 

    [mysqld]max_allowed_packet=16M 

    使用mysql做数据库还原的时候，由于有些数据很大，会出现这样的错误：The MySQL Server returned this Error:MySQL Error Nr.2006-MySQL server has gone away。我的一个150mb的备份还原的时候就出现了这错误。解决的方法就是找到mysql安装目录，找到my.ini文件，在文件的最后添加：max_allowed_packet = 10M(也可以设置自己需要的大小)。 max_allowed_packet 参数的作用是，用来控制其通信缓冲区的最大长度。

    来自 http://www.cnblogs.com/bisonjob/archive/2009/08/18/1548611.html                            

     

     

     

     

     

     

     

     

    告诉你如何解决MySQL server has gone away问题

    2011-05-11 13:48 李惟 博客园 我要评论(1) 字号：T | T                                    
    一键收藏，随时查看，分享好友！                                    

    最近做网站有一个站要用到WEB网页采集器功能，当一个PHP脚本在请求URL的时候，可能这个被请求的网页非常慢慢，超过了mysql的 wait-timeout时间，然后当网页内容被抓回来后，准备插入到MySQL的时候，发现MySQL的连接超时关闭了，于是就出现了“MySQL server has gone away”这样的错误提示，解决这个问题，我的经验有以下两点，或许对大家有用处。

    AD：2013云计算架构师峰会超低价抢票中                                    

    最近做网站有一个站要用到WEB网页采集器功能，当一个PHP脚本在请求URL的时候，可能这个被请求的网页非常慢慢，超过了mysql的 wait-timeout时间，然后当网页内容被抓回来后，准备插入到MySQL的时候，发现MySQL的连接超时关闭了，于是就出现了“MySQL server has gone away”这样的错误提示，解决这个问题，我的经验有以下两点，或许对大家有用处：

    第一种方法：                                    

    当然是增加你的 wait-timeout值，这个参数是在my.cnf(在Windows下台下面是my.ini）中设置，我的数据库负荷稍微大一点，所以，我设置的值 为10，（这个值的单位是秒，意思是当一个数据库连接在10秒钟内没有任何操作的话，就会强行关闭，我使用的不是永久链接 （mysql_pconnect),用的是mysql_connect,关于这个wait-timeout的效果你可以在MySQL的进程列表中看到 （show processlist) ），你可以把这个wait-timeout设置成更大，比如300秒，呵呵，一般来讲300秒足够用了，其实你也可以不用设置，MySQL默认是8个小 时。情况由你的服务器和站点来定。

    第二种方法：

    这也是我个人认为最好的方法，即检查 MySQL的链接状态，使其重新链接。

    可能大家都知道有mysql_ping这么一个函数，在很多资料中都说这个mysql_ping的 API会检查数据库是否链接，如果是断开的话会尝试重新连接，但在我的测试过程中发现事实并不是这样子的，是有条件的，必须要通过 mysql_options这个C API传递相关参数，让MYSQL有断开自动链接的选项（MySQL默认为不自动连接），但我测试中发现PHP的MySQL的API中并不带这个函数，你重新编辑MySQL吧，呵呵。但mysql_ping这个函数还是终于能用得上的，只是要在其中有一个小小的操作技巧：

    这是我的的数据库操作类中间的一个函数

    我需要调用这个函数的代码可能是这样子的

    ping()这个函数先检测数据连接是否正常，如果被关闭，整个把当前脚本的MYSQL实例关闭，再重新连接。

    经 过这样处理后，可以非常有效的解决MySQL server has gone away这样的问题，而且不会对系统造成额外的开销。

    今天遇到类似的情景，MySQL只是冷冷的说：MySQL server has gone away。

    大概浏览了一下，主要可能是因为以下几种原因：                                    

    一种可能是发送的SQL语句太长，以致超过了max_allowed_packet的大小，如果是这种原因，你只要修改my.cnf，加大max_allowed_packet的值即可。

    还有一种可能是因为某些原因导致超时，比如说程序中获取数据库连接时采用了Singleton的做法，虽然多次连接数据库，但其实使用的都是同一个连接，而且程序中某两次操作数据库的间隔时间超过了wait_timeout（SHOW STATUS能看到此设置），那么就可能出现问题。最简单的处理方式就是把wait_timeout改大，当然你也可以在程序里时不时顺手mysql_ping()一下，这样MySQL就知道它不是一个人在战斗。

    解决MySQL server has gone away                                    

    1、应用程序（比如PHP）长时间的执行批量的MYSQL语句。最常见的就是采集或者新旧数据转化。                                    

    解决方案：                                    

    在my.cnf文件中添加或者修改以下两个变量：

    wait_timeout=2880000                                    

    interactive_timeout = 2880000                                    

    关于两个变量的具体说明可以google或者看官方手册。如果不能修改my.cnf，则可以在连接数据库的时候设置CLIENT_INTERACTIVE，比如：

    sql = "set interactive_timeout=24*3600";                                    

    mysql_real_query(...)                                    

    2、执行一个SQL，但SQL语句过大或者语句中含有BLOB或者longblob字段。比如，图片数据的处理                                    

    解决方案：                                    

    在my.cnf文件中添加或者修改以下变量：

    max_allowed_packet = 10M(也可以设置自己需要的大小)

    max_allowed_packet参数的作用是，用来控制其通信缓冲区的最大长度

    原文链接：http://www.cnblogs.com/aiyuchen/archive/2011/05/11/2042798.html

    来自 http://database.51cto.com/art/201105/261107.htm                                    

     

     


     

    You are here

    MySQL server has gone away

    Posted by ehamburg on

    Error log on my ISPs server reports the errors included below everyday. Any guidance on what is causing this is appreciated.

    ::

    [27-Jul-2007 06:38:19] PHP Warning: MySQL server has gone away
    query: INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', 'MySQL server has gone away\nquery: SELECT data, created, headers, expire FROM cache WHERE cid = &#039;menu:0:en&#039; in /home/hamburgi/public_html/orvwatch/includes/database.mysql.inc on line 121.', 2, '', 'http://www.orvwatch.com/pages/get_signs.html', '', '64.34.145.201', 1185539899) in /home/hamburgi/public_html/orvwatch/includes/database.mysql.inc on line 121
    [27-Jul-2007 06:38:19] PHP Warning: MySQL server has gone away
    query: INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', 'MySQL server has gone away\nquery: SELECT DISTINCT(p.perm) FROM role r INNER JOIN permission p ON p.rid = r.rid WHERE r.rid IN (1) in /home/hamburgi/public_html/orvwatch/includes/database.mysql.inc on line 121.', 2, '', 'http://www.orvwatch.com/pages/get_signs.html', '', '64.34.145.201', 1185539899) in /home/hamburgi/public_html/orvwatch/includes/database.mysql.inc on line 121
    [27-Jul-2007 06:38:19] PHP Warning: MySQL server has gone away
    query: INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', 'MySQL server has gone away\nquery: SELECT * FROM system WHERE type = &#039;theme&#039; in /home/hamburgi/public_html/orvwatch/includes/database.mysql.inc on line 121.', 2, '', 'http://www.orvwatch.com/pages/get_signs.html', '', '64.34.145.201', 1185539899) in /home/hamburgi/public_html/orvwatch/includes/database.mysql.inc on line 121
    [27-Jul-2007 06:38:19] PHP Warning: MySQL server has gone away
    query: INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', 'MySQL server has gone away\nquery: SELECT title, cid FROM aggregator_category ORDER BY title in /home/hamburgi/public_html/orvwatch/includes/database.mysql.inc on line 121.', 2, '', 'http://www.orvwatch.com/pages/get_signs.html', '', '64.34.145.201', 1185539899) in /home/hamburgi/public_html/orvwatch/includes/database.mysql.inc on line 121
    [27-Jul-2007 06:38:19] PHP Warning: MySQL server has gone away
    query: INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', 'MySQL server has gone away\nquery: SELECT * FROM system WHERE type = &#039;theme&#039; in /home/hamburgi/public_html/orvwatch/includes/database.mysql.inc on line 121.', 2, '', 'http://www.orvwatch.com/pages/get_signs.html', '', '64.34.145.201', 1185539899) in /home/hamburgi/public_html/orvwatch/includes/database.mysql.inc on line 121
    [27-Jul-2007 06:38:19] PHP Warning: MySQL server has gone away
    query: INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', 'MySQL server has gone away\nquery: SELECT data, created, headers, expire FROM cache WHERE cid = &#039;content_type_info&#039; in /home/hamburgi/public_html/orvwatch/includes/database.mysql.inc on line 121.', 2, '', 'http://www.orvwatch.com/pages/get_signs.html', '', '64.34.145.201', 1185539899) in /home/hamburgi/public_html/orvwatch/includes/database.mysql.inc on line 121
    [27-Jul-2007 06:38:19] PHP Warning: MySQL server has gone away
    query: INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', 'MySQL server has gone away\nquery: SELECT * FROM node_field nf in /home/hamburgi/public_html/orvwatch/includes/database.mysql.inc on line 121.', 2, '', 'http://www.orvwatch.com/pages/get_signs.html', '', '64.34.145.201', 1185539899) in /home/hamburgi/public_html/orvwatch/includes/database.mysql.inc on line 121
    [27-Jul-2007 06:38:19] PHP Warning: MySQL server has gone away
    query: INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', 'MySQL server has gone away\nquery: SELECT * FROM node_type_content nt ORDER BY nt.type_name ASC in /home/hamburgi/public_html/orvwatch/includes/database.mysql.inc on line 121.', 2, '', 'http://www.orvwatch.com/pages/get_signs.html', '', '64.34.145.201', 1185539899) in /home/hamburgi/public_html/orvwatch/includes/database.mysql.inc on line 121
    [27-Jul-2007 06:38:19] PHP Warning: MySQL server has gone away
    query: SELECT sid FROM sessions WHERE sid = 'da3843a261f55aa655fc3033221396c6' in /home/hamburgi/public_html/orvwatch/includes/database.mysql.inc on line 121
    [27-Jul-2007 06:38:19] PHP Warning: MySQL server has gone away
    query: INSERT INTO sessions (sid, uid, cache, hostname, session, timestamp) VALUES ('da3843a261f55aa655fc3033221396c6', 0, 0, '64.34.145.201', 'messages|a:1:{s:5:\"error\";a:8:{i:0;s:210:\"user warning: MySQL server has gone away\nquery: SELECT data, created, headers, expire FROM cache WHERE cid = &#039;menu:0:en&#039; in /home/hamburgi/public_html/orvwatch/includes/database.mysql.inc on line 121.\";i:1;s:223:\"user warning: MySQL server has gone away\nquery: SELECT DISTINCT(p.perm) FROM role r INNER JOIN permission p ON p.rid = r.rid WHERE r.rid IN (1) in /home/hamburgi/public_html/orvwatch/includes/database.mysql.inc on line 121.\";i:2;s:179:\"user warning: MySQL server has gone away\nquery: SELECT * FROM system WHERE type = &#039;theme&#039; in /home/hamburgi/public_html/orvwatch/includes/database.mysql.inc on line 121.\";i:3;s:185:\"user warning: MySQL server has gone away\nquery: SELECT title, in /home/hamburgi/public_html/orvwatch/includes/database.mysql.inc on line 121

    ⋅ Categories: Drupal 4.7.x                        

    Comments

                           

    Posted by brashquido on

    Perhaps this might help? At least give you a starting point...

    http://dev.mysql.com/doc/refman/5.0/en/gone-away.html                                        

    ----------------
    Dominic Ryan
    www.iis-aid.com                                        

    ----------------
    Dominic Ryan
    www.iis-aid.com                                

                           

    Posted by anti-derivative on

    This was happening to me with lighty 1.4.13. This is the version that was listed as most up to date when doing an apt-get install on ubuntu. The newest version (1.4.18) appears to fix the problem (but you must download and install it yourself):

    http://www.lighttpd.net/2007/9/9/1-4-18-speeding-up-a-bit                                        

    Some people were kind enough to toss some .deb files on that page.

                           

    Posted by rokea on

    Hello,

    I had the same problem, i finally understood that my drupal install was getting too big, and it needed some mysql tweaking. Here is the solution that worked for me:

    http://drupal.org/node/186384#comment-284542                                        

                               

    Posted by muhammad.tanweer on

    This one worked for me. I would like to add a little explanation.

    1 - open the my.ini file.
    2 - you might not have this (max_allowed_packet) line already there.
    3 - So you need to add this line at some point in this file.

    [mysqld]
    max_allowed_packet=24M                                                

    4 - Save the file
    5 - Restart wamp services and you are good to go.. :)

    Muhammad.
    http://www.drupalxpert.com/                                            

    Muhammad Tanweer
    http://www.app-desk.com                                    

                                   

    Posted by robeson on

    I was getting this error on multiple pages referencing multiple modules so I struggled to pinpoint the issue. Disabling the Update Status module didn't do anything. When I moved the database to my local MAMP server it was fine, but on the production WAMP server using Zend, the error came up all over the place, even though the MySQL configuration was exactly the same.

    Adding "max_allowed_packet = 64M" to the my.ini file and restarting MySQL service did the trick. I'm still not sure why a 1M (default) max_allowed_packet on the local server works but breaks on the production server, but I'm glad to have a solution!

                                   

    Posted by bajah on

    if you are using xampp for linux, then the max_allowed_packet is in the my.cnf file found in the etc folder
    i just configured it and it works fine.

    Bajah

    A little knowledge is a dangerous thing. So is a lot.

    Albert Einstein

                           

    Posted by abramo on

    MySql : "Warning: MySQL server has gone away" - Tune MySql to resolve this problem                                        

                           

    Posted by sdelbosc on

    I am using MySQL 5 with persistent connections between the web server and the database server.

    I had the same problem: "MySQL server has gone away" and increasing max_allowed_packet variable did not fix anything.

    This problem happened after very long scripts which actually exceeded MySQL wait_timeout variable.

    One solution could have been to increase wait_timeout. My problem was that wait_timeout is also used to close persistent connection after a long inactivity. I did not want to keep such connections opened if they were unused.

    So I tried to detect such failure and manually reconnect the web server to the database.

    My changes:

    <?php
    /**
    * Activate a database for future queries.
    *
    * If it is necessary to use external databases in a project, this function can
    * be used to change where database queries are sent. If the database has not
    * yet been used, it is initialized using the URL specified for that name in
    * Drupal's configuration file. If this name is not defined, a duplicate of the
    * default connection is made instead.
    *
    * Be sure to change the connection back to the default when done with custom
    * code.
    *
    * @param $name
    *   The name assigned to the newly active database connection. If omitted, the
    *   default connection will be made active.
    *
    * @return the name of the previously active database or FALSE if non was found.
    */
    /* Replacement of:
    function db_set_active($name = 'default', $reset = 0) {
    by: */
    function db_set_active($name = 'default') {
      global     $db_url, $db_type, $active_db;
      static     $db_conns;
    // Add of:
          if ( $reset == 1 ) {
            $key = array_search($active_db, $db_conns, TRUE);
        if (     $key !== FALSE ) {
              $name = $key;
          unset(    $db_conns[$name]);
        }
      }
      if (!isset(    $db_conns[$name]) || $reset == 1) {
            // Initiate a new connection, using the named DB URL specified.
            if (is_array($db_url)) {
              $connect_url = array_key_exists($name, $db_url) ? $db_url[$name] : $db_url['default'];
        }
        else {
              $connect_url = $db_url;
        }
            $db_type = substr($connect_url, 0, strpos($connect_url, '://'));
            $handler = "./includes/database.$db_type.inc";
        if (    is_file($handler)) {
          include_once     $handler;
        }
        else {
              drupal_maintenance_theme();
              drupal_set_title('Unsupported database type');
          print     theme('maintenance_page', '<p>The database type '. theme('placeholder', $db_type) .' is unsupported. Please use either <var>mysql</var> for MySQL 3.x &amp; 4.0.x databases, <var>mysqli</var> for MySQL 4.1.x+ databases, or <var>pgsql</var> for PostgreSQL databases. The database information is in your <code>settings.php</code> file.</p>
    <p>For more help, see the <a href="http://drupal.org/node/258">Installation and upgrading handbook</a>. If you are unsure what these terms mean you should probably contact your hosting provider.</p>'    );
          exit;
        }
            $db_conns[$name] = db_connect($connect_url);
      }
          $previous_db = $active_db;
          // Set the active connection.
          $active_db = $db_conns[$name];
      return     array_search($previous_db, $db_conns);
    }
    ?>                                            
    <?php
    /**
    * Helper function for db_query().
    */
    /* Replacement of:
    function _db_query($query, $debug = 0, $attempt=0) {
    by: */
    function _db_query($query, $debug = 0) {
      global     $active_db, $queries;
      if (    variable_get('dev_query', 0)) {
        list(    $usec, $sec) = explode(' ', microtime());
            $timer = (float)$usec + (float)$sec;
      }
          $result = mysql_query($query, $active_db);
      if (    variable_get('dev_query', 0)) {
            $bt = debug_backtrace();
            $query = $bt[2]['function'] . "\n" . $query;
        list(    $usec, $sec) = explode(' ', microtime());
            $stop = (float)$usec + (float)$sec;
            $diff = $stop - $timer;
            $queries[] = array($query, $diff);
      }
      if (    $debug) {
        print     '<p>query: '. $query .'<br />error:'. mysql_error($active_db) .'</p>';
      }
      if (!    mysql_errno($active_db)) {
        return     $result;
      }
      else {
    // Add of:
            if ( $attempt == 0 ) {
              db_set_active('unused', 1);
          return     _db_query($query, $debug, 1);
        }
            trigger_error(check_plain(mysql_error($active_db) ."\nquery: ". $query), E_USER_WARNING);
        return     FALSE;
      }
    }
    ?>                                            

    Could I have your opinion about this?

    Sylvain

    Capgemini Digital
    London, UK

                           

    Posted by cloneofsnake on

    I'm having the same problem on my freshly developed D6 site - no active users yet!!

    Found this bit online:

    IF you have an access to php.ini you can add this line :
    mysqli.reconnect = On                                            

    From what I've read, sounds like this should solve the issue... I know this error will go away if I refresh enough times... but that's unacceptable! And I'm afraid this will only get worse when more users sign on...

    However, I don't have access to the php.ini file as I'm on a shared hosting plan. So I was wondering if there's a way to override it? Like on Drupal's settings.php page, you could increase PHP's memory limit by adding:

    ini_set('memory_limit', '96M');                                        

    So, can we add "mysqli.reconnect = On" to the settings.php file too?

    None are more hopelessly enslaved than those who falsely believe they are free. - Goethe

                               

    Posted by pedrosp on

    The way out for this labyrinth for me has been disabling the (helpful btw) Update Status Module.
    I ask first to my hosting to enable max_allowed_packet=24M
    We've tried also to run mysqli.reconnect = On;
    But without good results.
    By the way, I'm quite happy with the technical support of my hosting service allowing that fine tuning.

    Then I saw this comment: http://acquia.com/node/45684#comments
    "Most often when there is slowness related to Update Status it has to do with the server blocking outbound HTTP requests."

    It works fine now !! Just Disable the module

    My workaround: Drupal 5.14 - Hosted in http://www.sync.es
    Update Status 5.x-2.3

                                   

    Posted by homeshop on

    Thank you for the info. It's been killing me. Now everything works perfect.

                                       

    Posted by nickbits on

    I have been having the same problem on and off for a month. Turning off Update Status seems to ahve solved the problem, at present!

    Nick

    ------------oOo----------------------
    Nick Young (www.nickbits.co.uk)

                                   

    Posted by kalligator on

    Thank you that worked for me as well on D 6.13!

                                   

    Posted by Rick Hood on

    Just reporting that this worked for me on a Drupal 6.13 site. I have had problems with Update Status module in the past on other sites.

    I was trying to install Nodequeue module and got the "Warning: MySQL server has gone away query: INSERT INTO watchdog..." error. Disabled Update Status and then Nodequeue installed no problem.

    Must be that Update Status does not work well on some modules?

                                   

    Posted by abnerzanetti on

    for my D6 only worked when i disable the Update Status module

    Ábner Zanetti
    Diretor de Tecnologia
    TruxSoft - Design e Tecnologia                                        

                                   

    Posted by dibya on

    I set the max_allowed_packet=16 M and it worked well for me. The long error code in MySMySQL server has gone away query: INSERT INTO watchdog gone.
    thanks

    dibya

                               

    Posted by ryanhunt on

    This fixed the problem I was having. Been working on it all night on a high availability instance of D6.

                               

    Posted by craigtockman on

    Thanks this worked for me with Drupal 6.22 running on MAMP.

                           

    Posted by kenorb on

    try db_tweaks module

                               

    Posted by the_g_bomb on

    drupal_tweaks is the new module that replaces this one.

    I found that adding it and enabling the db tweaks module allowed me to increase the Default wait_timeout value, which cleared the problem.

    --
    G

                           

    Posted by arun_varpe on

    Any more detail update on it ??? please share ...

    Arun varpe

                           

    Posted by Kevin_VE on

    I had a similar problem and couldn't find the problem. The problem was there when I wasn't logged in (anonymous), but when I was logged in (admin), the problem was no longer there. The only difference was the (re)captcha module, so I turned it off. The problem was gone, but now I had to find a new captcha modules >> I'm going to try Mollom.

                           

    Posted by leewoodman on

    Spent several hours with this problem and eventually switched off update status module and the problem went away

    Lee

                               

    Posted by Juc1 on

    sub

                           

    Posted by stevenaburton on

    I installed the DB Maintenance module and optimzied all the cache tables. This resolved the problem for me.

                               

    Posted by Ivanhoe123 on

    Have the same error on D7 and cannot create new content (new panel specifically).

    Tried disabling update module, making changes in the MySQL config (up to 64MB) but still no solution.

                           

    Posted by Ivanhoe123 on

    Subscribing; have the same error on D7 and cannot create new content (new panel specifically).

    Tried disabling update module, making changes in the MySQL config (up to 64MB) but still no solution.

    [EDIT]

    Seems that token + entity tokens were taking too much resources. I have about a dozen of content types with many fields so the token accordion was pretty long. I disabled the metatag module and it worked again.

                       

    Posted by jackbravo on

    Drupal 7 had a bug that left DB connections open. Next release 7.18 will have a fix for this. http://drupal.org/node/843114

    来自 https://drupal.org/node/163145

  • includes/database.mysql.inc

  • includes/database.inc

  1. $str = file_get_contents(’http://www.tianqiyugao.net’);    

  2.  

  3. $db->ping();//经过前面的网页抓取后，或者会导致数据库连接关闭,检查并重新连接    

  4.  

  5. $db->query(’select * from table’);   

  6. function ping(){    

  7.  

  8.     if(!mysql_ping($this->link)){    

  9.  

  10.         mysql_close($this->link); //注意：一定要先执行数据库关闭，这是关键    

  11.  

  12.         $this->connect();    

  13.  

  14.     }    

  15.  

  16. }  



这个是自己亲自做的,报下面的错,是  (修改my.cnf 的 max_allowed_packet 为 20M,然后重启mysql服务器,问题解决)       


[21-Nov-2022 09:57:02 Asia/Shanghai] PHP Fatal error:  Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 2006 MySQL server has gone away' in /www/web/jsfaq_luxshare-ict_com/public_html/includes/database/database.inc:2278

Stack trace:

#0 /www/web/jsfaq_luxshare-ict_com/public_html/includes/database/database.inc(2278): PDOStatement->execute(Array)

#1 /www/web/jsfaq_luxshare-ict_com/public_html/includes/database/database.inc(744): DatabaseStatementBase->execute(Array, Array)

#2 /www/web/jsfaq_luxshare-ict_com/public_html/includes/database/database.inc(2457): DatabaseConnection->query('SELECT expire, ...', Array, Array)

#3 /www/web/jsfaq_luxshare-ict_com/public_html/includes/lock.inc(167): db_query('SELECT expire, ...', Array)

#4 /www/web/jsfaq_luxshare-ict_com/public_html/includes/lock.inc(146): lock_may_be_available('theme_registry:...')

#5 /www/web/jsfaq_luxshare-ict_com/public_html/includes/theme.inc(449): lock_acquire('theme_registry:...')

#6 /www/web/jsfaq_luxshare-ict_com/public_html/includes/bootstrap.inc(460): ThemeRegistry->set in /www/web/jsfaq_luxshare-ict_com/public_html/includes/database/database.inc on line 2278


普通分类: 
mysql
Powered by Drupal

友情链接

校园好文网

 www.shipingzhong.cn  个人技术网_前端_后台    备案号:苏ICP备18010659号-2