在本节中,还介绍了出现查询错误期间,与丢失了服务器连接有关的事宜。

MySQL服务器不可用错误的最常见原因是服务器超时以及连接已关闭。在该情况下,通常能见到下述错误代码之一(具体的错误代码与操作系统有关):

错误代码

描述

CR_SERVER_GONE_ERROR

客户端无法将问题发送至服务器。

CR_SERVER_LOST

写入服务器时客户端未收到错误,但也未获得问题的完整答案(或任何答案)。

在默认情况下,如果未发生任何事,8小时后服务器将关闭连接。也可以在启动mysqld时,通过设置wait_timeout变量更改时间限制。请参见5.3.3节,“服务器系统变量”.

如果有1个脚本,你仅需要再次发出查询,让客户端再次进行自动连接即可。其中,假定在客户端中启用了自动再连接功能(对于mysql命令行客户端,这是默认设置)。

MySQL服务器不可用错误的一些其他常见原因如下:

·         你(或db系统管理员)使用KILL语句或mysqladmin kill命令杀死了正在运行的线程。

·         你试图在关闭了与服务器的连接后运行查询。这表明应更正应用程序中的逻辑错误。

·         你在客户端一侧遇到TCP/IP连接超时错误。如果你使用了命令:mysql_options(..., MYSQL_OPT_READ_TIMEOUT,...)mysql_options(..., MYSQL_OPT_WRITE_TIMEOUT,...),就可能出现该问题。在该情况下,增加超时值可能有助于问题的解决。

·         你在服务器端遇到超时错误,而且禁止了客户端中的自动再连接功能(MYSQL结构中的再连接标志等于0)。

·         你正在使用Windows客户端,而且在发出命令之前服务器撤销了连接(或许是因为已超过wait_timeout

Windows平台上出现问题的原因,在某些情况下,将TCP/IP连接写入服务器时,MySQL未收到来自操作系统的错误,但当试图从连接读取答案时出现错误。

在该情况下,即使MYSQL结构中的再连接标志等于1MySQL也不会执行自动再连接并再次发出查询,这是因为它不知道服务器是否收到原始查询。

对此的解决方式是:如果自上一次查询以来经过了较长时间,在连接上执行mysql_ping(正是MyODBC所作的);或在mysqld服务器上将wait_timeout设置得很高,使之实际上不存在超时。

·         如果你向服务器发出了不正确或过大的查询,也会遇到这类问题。如果mysqld收到过大或无序的信息包,它会认为客户端出错,并关闭连接。如果需要执行较大的查询(例如,正在处理大的BLOB列),可通过设置服务器的max_allowed_packet变量,增加查询限制值,该变量的默认值为1MB。或许,你还需增加客户端上的最大信息包大小。关于设置信息包大小的更多信息,请参见A.2.9节,“信息包过大”

·         如果你的客户端低于4.0.8而且你的服务器高于4.0.8,当你接收16MB或更大的信息包时,可能会丢失连接。

·         如果MySQL是用“--skip-networking”选项启动的,也会见到MySQL服务器不可用错误。

·         你遇到了执行查询时服务器宕机的缺陷。

通过执行mysqladmin version并检查服务器的正常工作时间,可检查服务器是否宕机并重启。如果客户端连接是因mysqld崩溃和重启而断开的,应将重点放在查找崩溃你方面。首先应再次检查发出的查询是否再次杀死了服务器。请参见A.4.2节,“如果MySQL依然崩溃,应作些什么”

用“--log-warnings=2选项启动mysqld,可获得关于连接的更多信息。这样,就能将某些断开连接错误记录到hostname.err文件中。请参见5.11.1节,“错误日志”

如果你打算创建与该问题有关的缺陷报告,务必包含下述信息:

1.    指明MySQL服务器是否宕机。通过服务器错误日志可发现这方面的信息。请参见A.4.2节,“如果MySQL依然崩溃,应作些什么”

2.    如果特定查询杀死了mysqld,而且在运行查询前用CHECK TABLE检查了涉及的表,你是否能提供可重复的测试范例?请参见E.1.6节,“如果出现表崩溃,请生成测试案例”

3.    MySQL服务器中,系统变量wait_timeout的值是什么?mysqladmin variables给出了该变量的值)。

4.    你是否尝试使用“--log”选项来运行mysqld,以确定是否在日志中出现问题?

另请参见A.2.10节,“通信错误和失效连接”

请参见1.7.1.2节,“请教问题或通报缺陷”