Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
EPUB - 7.5Mb
HTML Download (TGZ) - 7.2Mb
HTML Download (Zip) - 7.2Mb


B.5.2.9 MySQL サーバーが存在しなくなりました

このセクションでは、関連する「クエリー中にサーバーへの接続が失われました」というエラーについても説明します。

「MySQL サーバーが存在しなくなりました」というエラーのもっとも一般的な原因は、サーバーがタイムアウトして接続が閉じられた場合です。この場合は、通常、次のいずれかのエラーコードを受け取ります (受け取るエラーコードはオペレーティングシステムによって異なります)。

エラーコード 説明
CR_SERVER_GONE_ERROR クライアントはサーバーに問い合わせを送信できませんでした。
CR_SERVER_LOST クライアントはサーバーに書き込むときにエラーを受け取りませんでしたが、問い合わせに対する完全な応答 (または何らかの応答) が得られませんでした。

デフォルトでは、何も発生しなかった場合、サーバーは 8 時間後に接続を閉じます。この時間制限を変更するには、mysqld を起動するときに wait_timeout 変数を設定します。セクション5.1.4「サーバーシステム変数」を参照してください。

スクリプトがある場合、クライアントが自動再接続を行うには、クエリーを再発行する必要があるだけです。これは、クライアントの自動再接続を有効にしている (mysql コマンド行クライアントのデフォルト) ことが前提です。

「MySQL サーバーが存在しなくなりました」というエラーのほかの一般的な原因を次に示します。

  • ユーザー (またはデータベース管理者) が実行中のスレッドを KILL ステートメントまたは mysqladmin kill コマンドを使用して強制終了した。

  • サーバーへの接続を閉じたあとにクエリーを実行しようとした。これはアプリケーションの論理エラーを示しており、修正する必要があります。

  • 別のホスト上で実行されているクライアントアプリケーションに、そのホストから MySQL サーバーに接続するために必要な権限がない。

  • クライアント側で TCP/IP 接続がタイムアウトした。これは、コマンド mysql_options(..., MYSQL_OPT_READ_TIMEOUT,...) または mysql_options(..., MYSQL_OPT_WRITE_TIMEOUT,...) を使用している場合に発生することがあります。この場合は、タイムアウト値を増やすと問題が解決されることがあります。

  • サーバー側でタイムアウトが発生し、クライアントの自動再接続が無効にされている (MYSQL 構造体の reconnect フラグが 0 と等しい)。

  • Windows クライアントを使用していて、コマンドが発行される前にサーバーによって接続がドロップされた (おそらく wait_timeout が期限切れになったため)。

    Windows での問題は、TCP/IP 接続をサーバーに書き込むときに MySQL が OS からエラーを受け取らず、接続から応答を読み取ろうとしたときにエラーを受け取ることです。

    この問題の解決策は、最後のクエリーから長い時間がたっている場合に接続に対して mysql_ping() を実行するか (これは Connector/ODBC が行なっていることです)、mysqld サーバーで wait_timeout に事実上タイムアウトすることがないような高い値を設定することです。

  • 間違ったクエリーまたは長すぎるクエリーをサーバーに送信した場合にも、これらのエラーを受け取ることがあります。mysqld が長すぎるパケットまたは順序が間違っているパケットを受け取ると、クライアントで何らかの問題が発生していると見なして、接続を閉じます。大きなクエリーが必要な場合 (たとえば、大きな BLOB カラムを操作している場合)、クエリーの制限を緩和するには、サーバーの max_allowed_packet 変数 (デフォルト値は 1M バイト) を設定します。クライアント側の最大パケットサイズも増やす必要がある場合もあります。パケットサイズの設定については、セクションB.5.2.10「パケットが大きすぎます」を参照してください。

    多数の行を挿入する INSERT ステートメントまたは REPLACE ステートメントも、これらの種類のエラーの原因となることがあります。これらのステートメントのいずれかは、挿入される行数に関係なくサーバーに単一の要求を送信します。このため、1 つの INSERT または REPLACE で送信される行数を減らすことによって多くの場合エラーを防ぐことができます。

  • また、16M バイト以上のパケットを送信する場合に、クライアントが 4.0.8 より古く、サーバーが 4.0.8 以降であると (またはその逆の場合)、接続を失うことがあります。

  • ホスト名のルックアップが失敗した場合に、このエラーが発生することもあります (たとえば、サーバーまたはネットワークが依存する DNS サーバーが停止した場合)。これは、MySQL が名前解決についてホストシステムに依存しているが、それが動作しているかどうかは知ることができないためです。MySQL が認識している範囲では、この問題はほかのネットワークタイムアウトと区別が付きません。

    --skip-networking オプションを指定して MySQL が起動された場合に、「MySQL サーバーが存在しなくなりました」というエラーが表示されることもあります。

    MySQL のポート (デフォルトは 3306) がファイアウォールによってブロックされていて、MySQL サーバーへのすべての接続が遮断される場合、このエラーの原因となることがある別のネットワークの問題が発生します。

  • アプリケーションで複数の子プロセスがフォークされ、すべての子プロセスが MySQL サーバーへの同じ接続を使用しようとした場合に、このエラーが発生することもあります。これは、各子プロセスが個別の接続を使用することによって防ぐことができます。

  • クエリーの実行中にサーバーが停止するバグが発生した。

MySQL サーバーが停止して再起動されたかどうかを確認するには、mysqladmin version を実行してサーバーの稼働時間を検査します。mysqld がクラッシュして再起動されたためにクライアント接続が切断された場合は、そのクラッシュの原因を見つけることに集中してください。クエリーを再び発行するとサーバーが再び強制終了されるかどうかを確認することから始めます。セクションB.5.4.2「MySQL が繰り返しクラッシュする場合の対処方法」を参照してください。

接続の喪失に関する情報をさらに取得するには、--log-warnings=2 オプションを指定して mysqld を起動します。これにより、一部の切断に関するエラーが hostname.err ファイルに記録されます。セクション5.2.2「エラーログ」 を参照してください。

この問題に関するバグレポートを作成する場合は、次の情報を含めてください。

セクションB.5.2.11「通信エラーおよび中止された接続」およびセクション1.7「質問またはバグをレポートする方法」も参照してください。


User Comments
  Posted by Devin Henderson on July 3, 2007
Like myself, you might be getting this bug because you have failed to properly upgrade from MySQL 4 to MySQL 5. Make sure you have run the 'mysql_upgrade' command:

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

For reference also see:

http://dev.mysql.com/doc/refman/5.0/en/upgrading-from-4-1.html
and
http://dev.mysql.com/doc/refman/5.0/en/repair-table.html
  Posted by Martin Mokrejs on April 28, 2008
This also happens when you use compression of the mysql connection handler and due to some limitations of mysql server which cannot return easily an error message. Instead, it just kills the connection without a message. So turn off the compression and remove the 'quick' option from /etc/my.cnf if you observe lost connections to get the message.

Read the answer from Michael Widenius:
http://bugs.mysql.com/bug.php?id=1011

<quote>
[19 Aug 2003 15:41] Michael Widenius

Sorry about the last bug entry, but it was not true. Sinisa had a patch pending but I
didn't approve of it as it didn't solve this problem for all cases.

This problem is already documented in the manual section
'MySQL server has gone away Error':

-----
You can also get these errors if you send a query to the server that is
incorrect or too large. If mysqld gets a packet that is too large.
or out of order, it assumes that something has gone wrong with the client and
closes the connection.
-----

We fixed this problem in 4.0 for not compressed packets but for
compressed packets it's VERY hard to fix it without having to allocate
a buffer bigger than max_allowed_packet, which would defeat the
purpose of this flag. Ane problem is that to be able to skip the
packet we have to decompress all packets in the stream and this would
make it easy for someone to force the server to allocate a lot of big
packets even if the MySQL administrator has forbidden this.

I looked into fixing this but didn't come up with a good way to to fix
it without a major amount of work (8-16 hours).

As we have more important things on our todo (this is not a serious
bug) we have to put this on hold for now and look at fixing this in
4.1 or 5.0.

The easy way to avoid this problem is to ensure that max_allowed_packet is set bigger in
the mysqld server than in the client and that all clients uses the same value for
max_allowed_packet.

Regards,
Monty
</quote>

and other reports:
http://bugs.mysql.com/bug.php?id=10609
http://bugs.mysql.com/bug.php?id=4143

  Posted by Angelo Mondati on September 1, 2008
Be aware of multi-threading.

I have used a c++ singleton class to encapsulate the mysql C API.
Using the same 'instance' of the class in two separate threads(or sharing the same mysql connection between threads), has raised this kind of errors (CR_SERVER_GONE_ERROR or CR_SERVER_LOST) when one thread ,which runs every 30 seconds, execute a query or a SQL command in the same time of the other thread.
  Posted by Paul Kenjora on May 8, 2009
I received this error when importing a mysqldump.

The simplest fix is to limit the packet size at export:

mysqldump somedb --max_allowed_packet=16 | gzip > /mnt/somedb.mysql.gz

Then on the import side ensure my.cnf [mysqld] has at least:

set-variable = max_allowed_packet=16M

If that doesn't work then try removing the extended inserts explicitly at dump...

mysqldump somedb --max_allowed_packet=16 --skip-extended-insert | gzip > /mnt/somedb.mysql.gz

Remember to restart your server using:

/sbin/service mysqld restart

  Posted by James R. on July 10, 2009
For all those having this problem and using PHP:

my problem was solved by downgrading PHP from 5.3.0 to 5.2.10.

Maybe it's the MySQL native driver in PHP not mature enough causing the problem.

I've tried all the solutions - to no avail - including:

-> setting up this options in my.ini/mysqld:

wait_timeout=28800

interactive_timeout = 28800

max_allowed_packet=32M

-> editing php.ini:

changing -> mysqli.reconnect = Off to On

-> checking all the versions of mysql I had available + mysql_upgrade

-> playing with php code:

forcing the connection to be closed after every query and reopening it immediately after that for the next query - this enabled forcing more queries to run but not all
  Posted by David Torre on September 26, 2009
Right after I upgraded to PHP 5.3 I started getting these "MySQL server has gone away" errors on almost every other page request from the apache server. I tried a few ideas that didn't work. Here is the solution: I changed all my mysql_pconnect() statements to mysql_connect(). It fixed the problem. For some reason PHP 5.3 DOES NOT LIKE persistent connections.
  Posted by Paul Purczel on June 22, 2010
I have had this problem for weeks, using a large query with joins. The way I managed to rectify the problem was not with the mysql settings, it was actually in php.ini
setting connect_timeout = 300
and default_socket_timeout = 300
they are set to default at 60 seconds and this caused my problem.
  Posted by Mike Kelly on March 17, 2011
I ran into this same error, and as a previous comment noted, and I think bears repeating, was eliminated when I stopped using persistent connections to connect to the MySQL database.
That is, I changed my "PDO::ATTR_PERSISTENT => true" settings to "PDO::ATTR_PERSISTENT => false" and the problem went away.
And there was great rejoicing.
  Posted by MySQL User on May 4, 2011
After I increased my max packet to 2000M, I watched htop when doing the sql import that kept failing and discovered the server went away when I ran out of ram and swap...
  Posted by Chris Calender on May 10, 2011
For those seeing this from PHP scripts, and you've already checked the other items listed above, then ensure your script is calling mysql_free_result when it completes.
  Posted by Jorge Torralba on June 2, 2011
I struggled with this all day. I was uploading two files and then inserting data into the table. The only difference with the files was their size. One would upload just fine and then the database update would take place using a prepared statement. All good. Then I would upload the other larger file which completed uploading but failed to update the database. In the end, what fixed my problem was setting mysqli.reconnect = On in php.ini. My only guess is that the larger file was taking longer to upload thus the db connection was timing out. As a side note, the file was NOT being stored in the db only info about the file.
  Posted by George Liu on August 27, 2011
Just a tip for WHM/Cpanel users experiencing this error it could be related to the WHM cronjob which runs during /scripts/upcp updates which updates WHM/Cpanel versions and checks for version updates to components such as MySQL server http://vbtechsupport.com/433/. Solution is to change when that cronjob is run to not coincide with peak mysql activity time.

  Posted by Radu Onofrei on December 12, 2011
We have found that this problem may occur also because of a bad nameserver, http://matrafox.info/mysql-error-messages-mysql-server-has-gone-away.html or your own cpanel server listed into resolv.conf
  Posted by BOB GALLEY on March 9, 2012
goto include/local
if there is configure.php, delete this file.
  Posted by Pavel Bazanov on June 3, 2013
In my case the problem ("Lost connection to MySQL Server during query") was in a corrupted dump file or in the misbehaving HDDs:

First, I made a dump on the main server and then copied that dump to the replication server. But it seems the replication server had some problems with its HDDs and the dump became corrupted, i.e. MD5 of the original dump file on the main server was different from MD5 of the dump copy on the replication server.
  Posted by Bill Plimpton on August 7, 2013
The key of making it work from command line is not forgetting this part
[mysqld]
max_allowed_packet = 1060M
  Posted by Anna Soseo on October 6, 2014
When you say : If you have a script, you just have to issue the query again for the client to do an automatic reconnection. This assumes that you have automatic reconnection in the client enabled
You can also put automatic reconnection on false to avoid server call. Anna from http://www.howcreateblog.com
Sign Up Login You must be logged in to post a comment.