主页 > MySQL教程 > 正文

MySQL server has gone away 处理方案

运用程序总会在每天早晨的时分出一次错,在运用程序日志中,我发现总有一些“MySQL server has gone away”这样的过错信息,可是查看数据库日志又并没有像它描绘那样真的gone away,请问这种过错是怎样发生的呢?怎样处理这个问题?

原因有二:

1.闲暇等候超时,最常见的原因

- 修正wait_timeout值

- 增加超时主动重连,运用mysql_ping()

2.通讯缓冲区太小

- 修正MySQL的max_allowed_packet值

运用程序(比方PHP)长期的履行批量的MYSQL句子。履行一个SQL,但SQL句子过大或许句子中含有BLOB或许longblob字段。比方,图片数据的处理。都简略引起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 参数的作用是,用来操控其通讯缓冲区的最大长度。 

最 近做网站有一个站要用到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这个函数仍是总算能用得上的,仅仅要在其中有一个小小的操作技巧: 

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

代码如下:

function ping(){ 
    if(!mysql_ping($this->link)){ 
        mysql_close($this->link); //留意:一定要先履行数据库封闭,这是要害 
        $this->connect(); 
    } 
}

我需求调用这个函数的代码或许是这姿态的

代码如下:

$str = file_get_contents('http://www.vztug.com'); 
$db->ping();//经过前面的网页抓取后,或许会导致数据库衔接封闭,查看并从头衔接 
$db->query('select * from table');

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参数的作用是,用来操控其通讯缓冲区的最大长度。

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履行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报告中会有吧。


上一篇:mysql并发操作问题
下一篇:mysql删去和更新操刁难功能的影响

PythonTab微信大众号:

Python技能交流合作群 ( 请勿加多个群 ):

群1: 87464755

群2: 333646237

群3: 318130924

群4: 385100854